Мне кажется, многие из нас время от времени задумывались о том, какие еще напраления работы можно бы освоить, чтобы лучше использовать свой потенциал и приблизить реализацию своих жизненных целей.
Можно попробовать освоить Heroku или получше разобраться в мобильном направлении. Много вариантов, и все они разные. И в тоже время - все они одинаков, так как подразумевает, что ты остаешься в той же програмисткой парадигме. И это не плохо, это т.н. "горизонтальная" карьера - улучшение, доведение до мастерства своих проф навыков - так, что ты становишься "лучшим среди равных".
Но дает ли нам жизнь в экосистеме Salesforce другие пути? Да, дает. Как насчет, чтобы стать SF консультатом (фактически "продаваном")?
Ну во-первых, это единственный путь в вертикальном росте в пределах конкретной IT фирмы и SF экосистемы в целом.
Во-вторых, ты сам становишься человек- оркестром, который обладает достаточным пониманием и возможностьями для самостоятельного развертывания бизнес-решения.
Но что должен знать и уметь SF консультант?
Я попробовал на вскидку вспомнить самые очевидные вещи:
(1) понимание жизненного цикла бизнес приложений.
(2) навыки работы с UML.
(3) Понимание содержания бизнес процессов в бизнес организациях в целом.
(4) Понимания того, как IT позволяет автоматизировать и помочь в выполненияя бизнесcов процессов в целом.
(5) Понимание как SF может решить те задачи которые стоят перед IT в бизнесе.
(6) Знание цен и лимитов SF.
(7) Понимание того, как нужно мигрировать с (или дополнять) уже существующих решений при переходе на SF.
Предлагаю обсудить эту тему - работу консультантом в целом и в частности обсудить какие-то интересные конкретные вещи из того арсенала, что знает консультант, но, вероято, не знает програмист.
спасибо
Я думаю что это вопрос в никуда. Тут наверное только чистые программисты сидят.
А вообще это очень актуальная проблема. Сколько раз ко мне, как к специfлисту SF, обращались люди, но я не мог им помочь потому что их интересовали именно вопросы покупки, возможностей из коробки, различия лицензий.
И получается так, что для 90% клиентов я абсолютно бесполезный специалист. Именно разработка кастомных решений интересует оставшихся 10%, а то и меньше.
Так что если есть возможность разобраться с "консультантом SF", то это будет ОГРОМНЫЙ плюс для тебя.
Но как я понимаю стать консультантом "просто так" как разработчиком SF не получится. Наверное тут без официального обучения и доступа к "закрытым" данным не обойтись.
Значит и обсуждать нечего.
Нужно немедленно изучать тему.
Начинаю.
Год назад купил небольшую книжку Force.com from Pilot to Enterprise-wide Adoption
Она не большая, около 45 машинописных страниц. Ив начале показалась мне чушью полной - вообще не понятно о чем весь этот пустой треп.
На днях я взял ее в руки. И понял что там описываются общие вопросы внедрения платформы. И хотя все описывается кратко и в общем, но там время от времени находишь ответы на вопросы.
Вот например там есть такая схема вараиантов "перехода" на SF с легаси платформы.
вертикальная ось: сложность легаси ситемы
|высокая
|
| tolerate------------------------------------extend
|
|
|
| eliminate----------------------------------------migrate
|
|низкая_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ высокая
горизонтальная ось: важность легаси системы для пользовтаеля
жирным указаны вараианты стратегии наших действий в зависимости от сложности\важности легаси системы.
но что занчит tolerate?
Что-то мне подсказывает что это из области высшей аналитики. Врядли малому бизнесу будут интересные все эти теории.
Я думаю тебе это пригодится только если ты захочешь устроиться в крупную фирму на должность аналитика (далеко не разработчика)
Так что давай ближе к практической части данной книги.
А так тема полезная, если продолжишь раскрывать тему своими словами я думаю будет полезно и тебе и нашим коллегам на форуме.
Как это из области высшей аналитики? И почему только для малого бизнеса?
Всмотритесь в диаграмму выше. С ней описывается ситуация перехода предприятия со старой платформы на СФ - а скоро в жизни таких задач будет много.
И говорится, что при переходе предприятия с существующей платформы на СФ следует применять 4 тактики в зависимости от сложности и важности предыдущей системы.
Если старая система несложна, но важна - то польностью мигрируйте ее на СФ,
Если старая система сложна и важна - то дополните ее СФом.
Если старая система несложна и неважна - ликвидируйте ее.
Если старая система сложна и неважна - tolerate it.
В каком формате книжка ?
У меня только в бумажном виде, и сканировать нельзя.
она небольшая, вот
http://www.amazon.com/Quick-Start-Guide-Implementing-force-com/dp/1477650105
у этого автора есть и другие книги
Короче я понял :))))))))))))))))))) Автор учит тебя не как внедрить СФ, а как навешать лапшу на уши клиента, раздуть процесс и срубить бабла. Хм 
в этом тоже надо талант иметь!!! Наверное аналитики СФ не просто так бабки зарабатывают.
Но скажу так, заинтересовал. Жду продолжения.
PS. Несмотря на то что я слишком критично отозвался рациональное зерно в этих строчках есть. Просто их надо рассматривать в контексте, а не отдельно :)
Когда 4 года назад я смотрел бумажные варианты их можно было по пальцам одной руки пересчитать :)и хотя времени очень мало, я все же стараюсь читать книжку указанную выше.
и в тех местах, где как мне раньше казалось, только словесная шелуха, начали проступать важные мысли. кроме того возникает понимание, что все что раньше училось про СФ (програмисткая часть) - это только один из пазлов, формирующий общую картину.
вот что интересного, что прямо указано в книжке: в связи с огромными стандарными поинт-энд-клик возможностями платформы СФ команда редуцирована до трех ролей: бизн архитектор (это как бизн аналист, но с полным арсеналом скилсов по поинт-энд-клик конфигурированию), програмист, пользователь.
В связи с тем, что отладку проводить гораздо проще, то Agile методика фактически не применяется - нет периода LOCK-DOWN требований вообще - все время можно доводить на ходу. это в книжке называется an emergent methodology.
Более того, focus on "good enough". т.е. деплой делается так быстро как только возможно, когда качесвто достигло уровня "сойдет", а доводить можно позже по фидбекам пользователей.
(примечание: здесь речь все же идет об использовании СФ для Business IT и когда мы готовим приложения непосредственно для заказчика, а не обобщенные приложения для Marketa)
кроме того, косвенно узнаю, что CRM в принципе явлется частью ERP и в целом относится к BSS.
и есть какие то нативные коннекторы для SAP и ORACLE. Вы когда нибудь подключали SF к SAP и ORACLE?
плюс есть фразы, просто красиво звучащие на английском, которые стоит запомнить, например,
в книжке все же описывается процесс внедрения СФ на предприятии, и собственно ставится бизнес задача "подмять" под СФ весь Бизнес ИТ предприятия как можно скорее (adoption of Business IT across the Enterprise).
Исходя из этого и даны многие рекомендации.
Но с другой стороны сама идея того, что вся СФ команда редуцирована до трех ролей, причем третий - это пользователь, которому нужно выкатывать работу как можно скорее и потом доводить на основе его фидбеков, это важный общий момент.
как вы уже догадались, эти идеи - "взять как можно больше", всю работу сделаеть небольшой командой "комбайнов" - это очень понравится хозяевам ИТ бизнеса - а значит все именно так и будет, и никак иначе.
Ну вот я и закончил прочтение той небольшой книжки о внедрении СФ на предприятии.
В ней много интересного из того, что же происходит вне зоны видимости разработчика, и это может дать некоторое понимание того, зачем мы делаем то, что делам (а делаем мы то, что нам велят делать). Плюс плох тот разработчик, кто не хочет стать Solition Architector or Technical lead.
И хочется вынести на обсуждение некоторые вещи, которые мне показались особенно интересны.
Integration
В связи с тем, что во многих случаях внедрение будет развиваться не по сценарию полного перехода со старой системы на новую, а в виде расширения существующей системы, встает вопрос интеграции. Плюс во многих случаях СФ может использоваться как CRM часть ERP, где ядром будет к примеру SAP, так что опять интеграция встает на первое место.
"Если вам нужно интеграция с наиболее используемыми десктопными бизнес инструментами как Лотус Нот или MS Excell или интеграция с ERP пакетами от Оракл или САП - СФ обеспечивает вас бесплатными, надежными нативными коннекторами."
Плюс можно использовать сторонние integration middleware или создать их самим.
Вопрос: у вас был опыт интеграции с дестокпными приложениями, с ERP, да и вообще любой опыт Application or Data integration?
Далее.
О Single Sign On (SSO).
Force.com offers the following ways to use SSO:
Federated authentication using SAML and
Delegated authentication.
Я так понял, что в случае когда СФ расширяет существующий функционал и\или используется как CRM внутри другой системы, СФ Орг или (что вероятно даже чаще) СФ Портал "за-айфремин" или указан в виде линка\ссылки в других приложениях, и пользователи единожды залогившиеся в базовое приложение бесшовно попадают в СФ орг или портал. И даже не чувствуют, что это что-то другое. Отлично? Плюс есть возможность создания орговых или портальных юзеров "на-лету" - в первый раз как они по SSO попадают в СФ. Не плохо?
Вы когда нибудь настраивали SSO в СФ?
И пока последнее.
Org Strategy.
Для меня было сюрпризом, что автор подробно обсуждаем возможность разбивки Решения на несколько СФ Оргов. Как я понимаю, такой подход может быть только связан с преодолением каких-то лимитов. Хотя мне казалось, что лучше все держать в одном орге.
И три варианта мулти-орг сценария.
1) Три (к примеру три) полностью независимых и не связанных Орга: Internal Org (finance, HR, IT, legal), Business org (vendors, partners, contractrs), Cosumer Org (marketing, sales, support).
2) Вариант с частично связанными Оргами:
Legasy system --> Master Org <--> 3 Orgs
причем свять между Master Org <--> 3 Orgs - это Salesforce-to Saleforce (S2S), а между самими конечными оргами связи нет.
3) И последний, очевидный вариант - это те же три Орга, связанные с друг другом через S2S. Связанные, но тем не менее разные Орги. Зачем? Почему? у меня нет на это ответа.
Сталкивались ли вы с мульти-орг Решениями?
Спасибо
Вопрос: у вас был опыт интеграции с дестокпными приложениями, с ERP, да и вообще любой опыт Application or Data integration?
Интеграцию делал и много в том числе и с десктопными приложениями. Здесь куча проблем. Если используете IE то лучшее или самое быстрое решение ActiveX. Если Другие браузеры, то однозначно плагин. Почему, да все потому что салесфорс использует разные домены и для того что бы наладить нормальную связь с приложением нужно однозначно знать с какием табом работаем и вот это и есть проблема.
Интеграция делается через вебсерсисы, s2s коннектор.
Далее.
О Single Sign On (SSO).
Force.com offers the following ways to use SSO:
Federated authentication using SAML and
Delegated authentication.
Я так понял, что в случае когда СФ расширяет существующий функционал и\или используется как CRM внутри другой системы, СФ Орг или (что вероятно даже чаще) СФ Портал "за-айфремин" или указан в виде линка\ссылки в других приложениях, и пользователи единожды залогившиеся в базовое приложение бесшовно попадают в СФ орг или портал. И даже не чувствуют, что это что-то другое. Отлично? Плюс есть возможность создания орговых или портальных юзеров "на-лету" - в первый раз как они по SSO попадают в СФ. Не плохо?
Вы когда нибудь настраивали SSO в СФ?
Сам не настраивал, но мы SSO сейчас использует в проэкте в банке. Как это работает :
1. Есть Active Directory и прокси.
2. Когда юзер вводит свой пароль от компьютера и после этого открывает браузер по средствам SSO сразу попадает внутрь салесфорса. Если нужны подробности могу уточнить у админа. Пока помню что нужен сертификат и federationId что-то в таком духе.
3) И последний, очевидный вариант - это те же три Орга, связанные с друг другом через S2S. Связанные, но тем не менее разные Орги. Зачем? Почему? у меня нет на это ответа.
Сталкивались ли вы с мульти-орг Решениями?
s2s - достаточно огранниченное решение и не работает с лукапами. хотя может уже и пофиксили.
Спасибо wilder.
у меня есть интерес к вопросам интеграции, и как освобожусь, хочу изучить тему.
Вот собственно ситуация с которой вероятно многие знакомы.
ПРоект начался когда-то и постоянно в Орг добаляются все новые и новые проекты, объединенные только формально единой организацией. Фактически совместно (не паралельно, а именно совместно - то есть используются одни и те же записи) используется только пара объектов - контакты да эккаунты, а в остальном у всех все разное и кастомное.
Вопрос: ну зачем, какой смысл загонять все в один Орг? вспомним инфу из книги:
Org Strategy:
Третий вариант: три Орга, связанные с друг другом через S2S. Связанные, но тем не менее разные Орги.
так и не понимаю, почему не раскидать все по нескольким Оргам: сейчас столько кода, тригеров и тест юнитов в одной куче...
Абсолютно верно. Под каждый проект свой дев орг! более того, под каждого девелопера свой дев орг (и синхронизацией через систему контроля версий)
Те варианты, которые описаны в книге - это только о ПРОДАКШН, это не о дев оргах - с ними то понятно, что их несколько.
Суть в том что весь Бизнес проект для Предприятия разбит на несколько Оргов которые шерят друг с другом через S2S только необходимую инфу. В результате код, WF rules/actions, юнит тесты не смешиваются.
но в жизни все проекты на одном Орге...
Сначала, хотел тебе возразить по поводу того, чтобы делить продакшены, но по ходу в этом что-то рациональное есть. Все-таки книгу писали умные люди :).
Хотя у меня сомнения в том что это будет стоить.
Вот типичный пример - 3 прода уже потребуют 3 лицензии для админа минимум + n*3 для каждого кому нужно будет иметь доступ ко всем оргам.
Остальное - можно разориться на написании и поддержании системы синхронизации.
Я думаю сложно будет объяснить лысому директору на гелике, что, товарищ, давай плати дофига бабок чтобы усложнить себе жизнь
Но опять же разделение данных очень интересная идея! Запомню, может когда применю.
Ну вот продолжу свои размышления на тему. Точнее сказать вновь подниму тему про документирование проектов.
Эта тема уже обсуждалась - не могу ее найти, но в целом было решено, что все что мы можем сделать - это максимально комментировать собсвтенный код.
Но проектная документация - это не только и не сколько описание того как работает наш код.
Проектная документация - это описание проекта в целом.
У меня нет по этому поводу BEST PRACTICE, у меня нет по этому поводу вообще никакой информации взятой из PRACTICE(из жизни).
Но есть мнение, что существует только одна единсвенная BEST PRACTICE - это имение думать собственной головой. В отутсвии других вариантов, так и прошлось сделать...
Вот идеи.
Разумеется вся основная проектная документация должна создаваться ПрМенеджером и БизАналитиками (позже,в процессе разработки или обслуживания эти документы уже дорписываются разными персонажами, в том числе и програмистами).
Первое что создает ПМ\БА - это UML диаграму с полным описание всех биз процессов которые нужно покрыть Приложением.
Вторым создается Объектаная схема ПРиложения - сдесь нужно смотреть сколько используется ресурсвов, может ли эта объектая конфигурация обслужить покрываемые биз процессы, как использутся стандартные или CRM объекты. Здесь кроме всего прочего становится ясно какие лицензии потребуются.
Третье что делается - это создается вторая версия UML диаграммы - теперь все те же процессы описаны на языке СФ - указано названия объектов, РекТайпов, Эппрувал ПРоцессов, тригеров и пр процессов. Фактчиски - это генеральная схема проекта. Любой грамотный в СФ человек, пришедший в проект позже может открыть эту схему и понять в целом что и как делает приложие.
и четветое, что мы ждем от ПМ\БА - это таблицу с Ролями - профайлами - это будет организационно -юзерской схемой проекта.
я представлю ее в виде двух join-утых таблиц.
посередине идет колонка в перечнем профалов. слево от этой колонки таблица ролей - каждая роль отдельная колонка - которая ниспадает и в какой то ячейке пересекается с назначенным профалом.
справа от колонки с перечнем профайлов - таблица объектов, где каждый объект это отдельная колонка и в ячейке указан доступ профайла к нему и какой РекТайп используется. Написание этого документа начинается с опредления ролей - так как они уже существуют в организации - заказчике.
UML и таблица пользователей - главные документы проекта.
кроме них есть еще документация для пользователей, наша собственная програмитская документация.
