Федя, дичь! Странные паттерны автоматизации
Время от времени нас в комментариях просят рассказать про реальные истории внедрения. Поскольку у нас почти нет ситуаций «купил — установил», мы часто работаем по ТЗ, чтобы сделать автоматизацию реально эффективной, а не номинальной, со всех сторон нас окружает 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 варианта с разным набором функций. И с каждой конфигурацией можно отлично работать — не нужно идти и искать что-то неизвестное и абсолютно дешёвое. Зачем, когда у одного разработчика весь оркестр
