Время от времени нас в комментариях просят рассказать про реальные истории внедрения. Поскольку у нас почти нет ситуаций «купил — установил», мы часто работаем по ТЗ, чтобы сделать автоматизацию реально эффективной, а не номинальной, со всех сторон нас окружает NDA. Рассказать реальную историю клиента = поссориться с ним (это мягко формулируя). Один раз нам удалось «выбить» историю внедрения из рекламного агентства, надеемся, что осенью получится ещё кое-что ;-) Зато нам ничего не мешает обобщить опыт и обезличенно рассказать хотя бы о том, как точно не надо делать (как говорится, все истории выдуманы, любые совпадения случайны).  Когда потенциальный заказчик приходит выбирать CRM-систему (геотрекинг, систему управления тикетами и т. д.), как правило, разработчик хочет познакомиться поближе. Мы не настаиваем на ужине при свечах или совместной прогулке на теплоходе (хотя почему бы и нет?), но нам важно знать ряд параметров: примерную структуру компании, вид деятельности, численность будущих пользователей, предыдущий опыт автоматизации, организацию процессов в компании. Это тот анамнез, который помогает понять, к какой категории относится компания и примерно представить, как заходить на работу с требованиями бизнеса. Без этих данных начало, да и продолжение разговора не то что невозможно, но крайне затруднительно. Конечно, часть информации разработчик может узнать сам, но то, как о ситуации рассказывает представитель компании, задаёт вполне внятные очертания будущего проекта автоматизации — прежде всего, потому что ранжируется главное, описываются проблемы, да в конце концов, строится диалог живых людей. Так вот, иногда компании решают, что разработчик — это не поставщик, не помощник, не опытный аналитик, а шпион, конкурент и враг номер один. А с врагом нужно молчать (как партизан), врать, бороться и всячески стараться вывести его на чистую воду. Нужно непременно спросить, «а зачем вы интересуетесь», «название компании вам ничего не даст», «мы бы не хотели раскрывать род деятельности до заключения договора» и т. д. Хорошо, что ещё никто не сказал «наше имя слишком известно, чтобы его называть». Конечно, такой подход контрпродуктивен: начиная с недоверия и неадекватного (что уж там!) поведения, компания-заказчик смазывает рамки проекта, путает разработчика и показывает, что сотрудничество с ней обещает быть «весёлым». К слову, практически у всех нормальных разработчиков корпоративных систем автоматизации (программ для бизнеса) хватает клиентов настолько, чтобы в свою очередь аккуратно уйти от сделки с изначально негативно настроенным заказчиком. Такие возражения хочется отрабатывать только под настроение. Этот случай типичный и относительно простой как по реагированию, так и по последствиям. Хуже, когда паттерны вылезают уже в процессе работы над проектом автоматизации. Компания-заказчик выкатывает требования, не совместимые с жизнью нормальной CRM: нужно, чтобы система делала всё. Абсолютно всё: от корпоративного портала до учёта ресурсов (это ещё приемлемо и реализуемо) вплоть до «своего» бухгалтерского учёта и онбординга сотрудников. Есть ещё вариация: требование реализовать что-то супер необычное, например, сделать модуль контроля бензина в автомобилях гаража (для этого есть отдельный софт и такие данные в CRM просто бессмысленны). Чаще всего мотивация у таких запросов минимально увязана с реальной оперативной работой: либо где-то «такое было», либо «пусть будет», либо «внедрять, так полный фарш».  Такой подход не кажется рациональным: с одной стороны, он сбивает фокус разработчика с основных задач проекта, с другой — при определённом ответе компании-внедренца он может стоить неадекватно больших денег (любой каприз…). Однако это тот случай, когда стоит пересмотреть проект заново и всё-таки понять, что будет реально использоваться, а что — нет. Нормальный разработчик тоже не заинтересован в том, чтобы большая часть внедрённой системы простаивала, сотрудники периодически натыкались на избыточную функциональность и раздражались. Практически каждая серьёзная программа для бизнеса — это сплав лучших практик и актуальных требований заказчиков, в ней есть практически всё, что нужно компании, и основная задача — довести дело до ума, адаптировать систему к требованиям конкретного бизнеса, доработать её, если это необходимо (а не переписать заново и не продать ненужный софт вместо нужного).  Впрочем, внедрение — это всегда отдельное приключение. Особенно если заказчик начинает менять условия и требования «на лету». Для таких щедрых на идеи людей договор и подписанное техническое задание — бренные, ничего не значащие бумажки. Решает только это: желание, видение и размах фантазии. И даже если всё новые и новые требования вполне логичны и адекватны, разработчик вынужден защищать свои интересы: либо сообщать, что ТЗ составлено и всё тут; либо предлагать составить новое ТЗ с изменениями, конечно, по новой стоимости разработки. Клиент, само собой, расстраивается, что он подарил гениальную идею, а с него за его же дар денег требуют. Разработчик расстраивается, осознавая, что эти новые «фичи» уже в голове заказчика и он видит другой финал проекта, а уже выполненные работы надо переделывать.  Самое интересное, что в итоге таких изменений на лету (ну вдруг они были приняты и оплачены) итоговый проект может получиться гораздо хуже первоначального, потому что нарушены планирование, структура проекта и логика построения работ. Ресурсы выделяются совершенно по другому принципу, и выходит… ну, как выходит. Поэтому лучше внимательно обследовать компанию и её процессы, спроектировать изменения, зафиксировать все параметры автоматизации и работать строго по плану. Если возникнет острая необходимость доработки какой-то фичи, это можно реализовать с новым ТЗ и со спланированными ресурсами — так, чтобы обе стороны были довольны результатом. Клиент хочет нормальную автоматизацию, но готов только экономить. Поскольку на лицензиях (подписке) и внедрении/доработках особо не сэкономишь, начинается экономия на всём остальном: на настройках — «мы сами все данные внесём, сами настроим, сами права раздадим, у нас Маша из продаж на веб-дизайнера три месяца училась»; как результат — кривые данные, дубли, потерянная информация; на безопасности — «а кому мы нужны?»; нужны-нужны;  на отчётах: фрилансер сделает; как итог — нерабочие фрагменты кода за деньги (иногда большие, чем взял бы разработчик);   на обучении — «ну мануал же есть, потыкают, разберутся»; итог — да и разбираться никто не стал, все работают, как раньше, без автоматизации. На самом деле, все эти задачи — не пустая формальность, а важные этапы процесса внедрения. Без нормальной реализации каждой из них срок окупаемости внедрённого ПО значительно растягивается, системы работают не в полную силу. Как правило, если компания закладывает бюджет на покупку приложений для бизнеса, бюджет на внедрение тоже есть. Экономии всегда есть место, и даже вендор может рассказать, где и на чём можно сэкономить. Но это точно не основные этапы проекта внедрения, не обучение и не техническая поддержка.  Вообще, это частный случай предыдущего, но лишь отчасти. Речь про безопасность. В какой-то момент компания решает, что все сотрудники — семья, и никаких тайн здесь быть не должно. Всем полный доступ к корпоративным системам за счёт компании! И никаких там ограничений по пулу IP-адресов или каким другим хитрым штукам — мы сотрудников отбирали, мы им верим. В итоге идеально реализуются сразу три вектора атаки на коммерчески значимую и чувствительную информацию: злоумышленный доступ внешних лиц (пароль можно передать, код из SMS сообщить), злоумышленный доступ сотрудников, неумышленный вред от пользователей (под кодовым названием руки из жо… «кривые ручонки»). И да, один пароль на всех — желательно тот, который можно легко запомнить. Какой бы дружной ни была команда, она состоит из людей. Жизнь людей меняется, иногда одним днём. Под воздействием внешних обстоятельств (мы условно поверим в лучшее и примем за данность, что виноват кто-то) сотрудник может склониться к каким-то действиям, более того, иногда даже считая их вполне себе невинными. Это, в свою очередь, может нанести ущерб компании и привести к далеко идущим последствиям (хищению клиентской базы, переманиванию сотрудников, разглашению ноу-хау и проч). Поэтому для целей и задач безопасности всё же стоит делить сотрудников на группы и строго разграничивать права доступа. Если боитесь обиды, скажите, что это для того чтобы не отвлекаться на ненужные модули — хотя, как показывает опыт, сотрудник работает по своим задачам и такие вопросы не задаёт. А вот если задал — это как раз повод задуматься и понаблюдать: он просто ревнивый к работе и хочет быть не хуже остальных, или же у него есть чёткий план и умысел (как правило, одними операциями с CRM дело не ограничивается, можно обнаружить и другие признаки шпионских вылазок коллеги). Классика жанра: или обучение не оплачивается в принципе, или сотрудников на обучении просто нет, «потому что им некогда, вот вам стажёр Вася, научите его, он всем расскажет». И вроде бы история с Васей имеет место быть и даже логична, но если только Вася не стажёр, а опытный сотрудник с техническим складом ума и отличным знанием бизнес-процессов — вот тут да, он легко может обучиться, стать внутренним экспертом и обучать каждого сотрудника за зарплату или премию (если у работодателя есть совесть). Иногда руководители сами не пускают сотрудников на обучение, чтобы не прерывать текущие процессы.  Это, конечно, очень плохо. Автоматизация, внедрение ПО для бизнеса — важная веха в жизни компании, это инвестиция в относительно рисковый инструмент, величина риска которого во многом зависит именно от людей, от того, насколько быстро и глубоко они готовы начать работать с новой для себя программой. Когда студент прогуливает лекции и семинары, он делает хуже не преподавателю, а себе — та же история с сотрудниками, которые просто откладывают старт работы. Да, обучение, особенно онлайн, это не панацея ото всех бед, но это ряд возможностей: узнать сразу обо всех проблемных и сложных местах, не натыкаясь на них в ходе рабочего процесса — просто потому что за много лет вендор знает о них всё; получить ответы на самые простые (не глупые, не стыдные!) вопросы, уточнить сложные моменты; сравнить свой уровень и уровень коллег, чтобы знать, к кому обращаться; сформировать общее понимание плана работы с системой; попробовать руками то, с чем предстоит работать, и не бояться что-то сломать (хотя мы с вами знаем, что сломать приложение весьма сложно). Ну и, кстати, это ещё один способ и повод пообщаться и понять, как можно скоординировать усилия. Совместное обучение — неплохой вариант небольшого тимбилдинга, поскольку все на равных, все работают над одной задачей, советуются.  Не особо мешающая внедрению история, которая может оказаться фатальной внутри организации. Команда никак не участвует в выборе и внедрении CRM (любой другой системы), все решения принимает одно лицо (не обязательно генеральный директор, но всегда при его молчаливом одобрении). Это лицо само формирует (не собирает) требования, само ведёт переговоры и тестирует системы, само взаимодействует с вендором. Возникает ощущение, что в компании больше никого нет, а Карабас-Барабас лучше знает, что нужно его театру. Хуже только ситуация, когда у такого сотрудника не хватает компетенций и знания бизнес-процессов, и он просто оказался самым…незанятым. Конечно, в России (и на территории СНГ) решение о внедрении автоматизации и вообще о любых изменениях, принятое снизу и исходящее снизу, от обычных сотрудников, казуистика, — почти всегда директива приходит сверху. Однако можно сообщить, что пора бы что-то внедрить и начать обсуждать детали, включать сотрудников в процесс, стимулировать их работать над новой общей задачей, а можно сообщить крайний срок перехода на новый формат работы и обозначить санкции, которые наступят для тех, кто не успеет разобраться. Стоит ли говорить, что во втором случае массовое сопротивление и бойкотирование (вполне возможно, даже очень тихое) использования нового программного обеспечения практически гарантировано. Если первый паттерн был самым линейным и однозначным, то этот — самый философский и многогранный. Это та медаль, у которой две стороны. Сторона первая: компания не может себе позволить дорогой и даже средний по цене софт и выбирает минимальную конфигурацию, лишь бы с чего-то начать. Сторона вторая: компания ошибается с выбором и хватается за какое-то слабенькое поделие по цене чашки кофе в день на сотрудника. Проблема в том, что в итоге такое поведение может обойтись значительно дороже сразу «нормальной покупки», но между тем импонирует стремление всё же с чего-то начать, попробовать, поискать точки роста эффективности (а там и «заработать на что-то поприличнее»). И бывают случаи, когда минимальная конфигурация оказывается тем оптимальным набором функциональности, с которым компании хорошо работать. А бывает, что поделие уходит с рынка вместе с клиентскими базами компаний. Поэтому здесь можно только дать совет: ищите минимальные конфигурации у надёжных разработчиков — как правило, им всегда есть что предложить. Для примера размах цен на RegionSoft CRM (возьмём 10 человек в компании, единоразовая покупка):  RegionSoft CRM Enterprise Plus + TRM на 10 пользователей — 247 740 р. RegionSoft CRM Standard + TRM на 10 пользователей — 101 260 р.  Как вы видите, разница в цене в 2,5 раза. Между ними ещё 4 варианта с разным набором функций. И с каждой конфигурацией можно отлично работать — не нужно идти и искать что-то неизвестное и абсолютно дешёвое. Зачем, когда у одного разработчика весь оркестр 🙂 Бывают более частные случаи обращений, бывают более массовые (например, спрос на какие-то «хайповые» штуки типа интеграции разных социальных сетей). Главное, разработчику вместе с заказчиком разобраться, действительно ли нужна конкретная функция, стоит ли тратить на неё ресурсы и будет ли они использоваться в дальнейшем. Нередки случаи, когда клиенты получают свою уникальную функциональность, не менее редки те, когда по договорённости с клиентом «его» фича попадает в общий релиз и делает системы лучше и современнее. Главное, думать и вести диалог, а не следовать за слухами и модой. Тогда автоматизация не разочарует.    Главный разработчик RegionSoft    Разработчик