Хочу рассказать про вспомогательные или дополнительные системы, которые пристраиваются рядом с основной или где-то у неё внутри.
Под вспомогательными системами я имею в виду ситуацию, когда мы, например, используем в качестве основной системы УПП или ERP и для того, чтобы она стала лучше, пытаемся встроить внутрь какой-нибудь CRM или BI. Или добавляем обмен данными с посторонней системой – интегрируемся с чем-нибудь для управления финансами или бизнес-процессами (типа Битрикс24).
Попытаюсь рассказать свою точку зрения о том, как правильнее решать такие задачи, и как это делать не стоит.
Как я оцениваю результат внедрения дополнительных систем
Важно понимать, что мое видение мира может отличаться от вашего. Я оцениваю результаты внедрения не по тому, как оно гладко идет или красиво завершается – подписанием акта, демонстрацией системы широкому кругу представителей заказчика.
Для меня главный результат внедрения – то, что осталось от системы через год, два, три после окончания проекта, насколько она продолжает использоваться, и какие процессы в ней реально работают.
Узнали человека? Думаю, все знакомы с понятием «систематическая ошибка выжившего» – его часто упоминает Нассим Талеб в своих книгах, особенно в «Одураченных случайностью».
Смысл понятия «ошибка выжившего» в том, что вероятность успешности какого-либо явления не стоит оценивать только по тем, у кого получилось. Намного интереснее оценивать по тем, у кого ничего вообще не получилось.
Когда я писал статью «Лёха смог: уйти из Мака в 35 лет и стать программистом» на меня нашло озарение, что на самом деле интереснее посмотреть, почему 80% людей, которые приходят в мир 1С, уходят из него по тем или иным причинам.
Та же самая ситуация с внедрением CRM, BI и прочих подобных систем.
По воскресеньям в 9 утра на СТС идет передача «Рогов в деле», где стилист Александр Рогов помогает людям преобразиться. Суть шоу проста: невзрачно одетые, без выраженного стиля люди подают туда заявки и говорят: «Рогов, измени мою жизнь».
Рогов выбирает участника, человек приезжает, его наряжают, делают прическу, иногда отмывают. И потом он весь такой обновленный выходит перед зеркалом, ему дарят цветы, и на этом все заканчивается.
На мой взгляд, большинство проектов по внедрению дополнительных систем выглядят точно так же. Команда берется за задачу широким фронтом: сделаем это, это и это, внедрим CRM так, чтобы люди приезжали посмотреть, как мы тут живем.
Мне всегда интересно, что происходит потом. Например, на НТВ раньше была передача о ремонте «Квартирный вопрос». В некоторых выпусках они показывали, что произошло с этим ремонтом спустя немного времени – и часто картина отличалась от первоначальной.
Мне всегда было интересно, что стало с теми людьми, которых преобразил Рогов? Как они выглядят на следующий день, когда лак с волос смыт, а новый стиль оказывается просто вещами в шкафу? Нам этого не показывают.
Итак, что там?
Я составил свою классификацию того, как заканчиваются проекты по внедрению вспомогательных систем. Сейчас кратко об этом расскажу.
Этот слайд – про вас. Я уверен, что в мире есть успешные внедрения вспомогательных систем. И хотя я сам таких не встречал, очень хочется верить, что есть внедрения, где реализовали все задуманное, все заработало, и после этого используется. Прямо как в шоу Рогова: человек прошел трансформацию, и через год его стиль не только сохранился, но даже стал лучше.
Вы только не подумайте, что я считаю себя истиной в последней инстанции и говорю, что у всех всё плохо. Нет, я уверен, есть хорошие системы, просто у меня маленький кругозор. Я всего 20 лет занимаюсь 1С, поэтому, наверняка, не всё видел.
Зачастую системы в итоге выглядят как старый «Буран» в ангаре. Она красивая, большая, ее построили, показали, взлетели один раз – и теперь она просто где-то валяется. Именно этим, на мой взгляд, заканчивается внедрение для большинства вспомогательных систем.
Классический пример. Люди купили CRM-систему и позвали подрядчиков, чтобы встроить ее в УПП. В результате подрядчики убедили заказчика, что нужно внедрение «по полной», и напридумывали порядка 30 всяких отчетов – которые и конверсию считают, и другие показатели. И хотя в B2B-компании конверсию считать не сказать, что нужно было, все 30 отчетов сделали, продемонстрировали – все шикарно!
Через год от всего проекта CRM остался только ввод контактной информации контрагентов. Но если ведение событий и ввод контактной информации – это все, что нужно от CRM, то это есть и в типовой конфигурации.
Еще часто бывает, что приобретенные системы так и остаются невостребованными.
Например, у меня на сопровождении был клиент из Питера. У него две однотипные базы, между которыми нужно было просто синхронизировать номенклатуру. Я говорю: это не проблема, можно сделать – это небольшая функция MDM-системы. Он говорит: а у нас есть MDM-система, в шкафу стоит, в коробочке.
Когда я приходил работать на один из заводов, там в шкафу стоял CRM.
Другое предприятие неподалеку от Челябинска недавно обратилось с просьбой автоматизировать юридический отдел. У них в шкафу стоит коробочка отраслевой конфигурации для автоматизации работы юридического отдела.
На заводе в Екатеринбурге, который занимается производством для автомобильной промышленности, стоит коробочка интеграции с PLM-системой, для того чтобы чертежи оттуда «засасывать». А чертежи «засасываются», но той внешней обработкой, которую написали еще до покупки PLM-системы.
Может, и у вас есть в шкафу какая-нибудь система или сервис, которые вы купили. Например, коробка Битрикс тоже любит «постоять». Или Битрикс24 как услугу купят на год. Год прошел – Битрикс24 где-то есть, но мы продолжаем работать в УПП.
Следующий кейс встречается реже и, в основном, на предприятиях с агрессивной системой управления.
Например, коммерческий директор, чтобы ему состояться, когда он только пришел, должен продемонстрировать некий системный результат. Коммерческий директор – он же продажами занимается. Если продажи плюс-минус выстроены, то какой тут системный результат может быть?
Например, освоение внешнего рынка. Но это долго и дорого, и очень рискованно, особенно сейчас. Многие из тех, кто пытался, на этом погорели – карьеру свою не сделали.
А некоторые коммерческие директора, чтобы сделать карьеру и показать системный результат, начинают внедрять CRM-систему. Они приносят буклет какой-нибудь компании, которая занимается CRM-системами и показывают: «Внедрим CRM и продажи вырастут на 10%».
Проект начинается. CRM внедрить не очень дорого – в миллион точно можно уложиться. Но заканчивается все плохо. На одном из предприятий, с которым я работаю, на этом погорели пять коммерческих директоров подряд. Каждый работал примерно один год. Один внедрял CRM, который внутри 1С, другой внедрял CRM на Битрикс. Третий внедрял amoCRM.
Продукты все прекрасные, но когда цель – выиграть «гонку героев» и получить себе какую-то прибавку, проект получается не очень успешный.
У большинства предприятий есть только 1С:Бухгалтерия, но нет никаких вспомогательных систем – ни платежного календаря, ни заявок на расход денег, ни CRM, ни системы для управления бизнес-процессами.
Но у них же никуда не делся процесс бюджетирования, например. Они же бюджетируют – согласуют реестр платежей так же, как это делали двадцать лет назад: приносят реестр финансовому директору на бумажке, а он говорит, кому заплатить, а кому не заплатить. Т.е. сам процесс бюджетирования у них есть.
Но почему я вообще сюда включил такие предприятия? У них же нет никакого проекта, никакой удачи или неудачи?
Потому что они изначально не хотят внедрять ненужный им вспомогательный продукт и повторять ошибки всех перечисленных выше проектов.
Например, люди работают в 1С:Бухгалтерии, обращаются в компанию-франчайзи и говорят: «Мы хотим автоматизировать планирование платежей. У нас всё простенько: есть заявки от закупщиков, совсем немного номенклатуры, три больших контрагента, платежи от которых всегда приходят вовремя. Ничего сложного. Сделайте для нас что-нибудь!»
Им говорят: «Вам нужна здоровенная система типа БИТ.ФИНАНС или Управление холдингом за один-два-три миллиона рублей». Получив такое коммерческое предложение, люди, которые купили 1С:Бухгалтерию по цене хороших тапок, говорят: «Не надо!». И работают по-прежнему в Excel.
По-настоящему успешные внедрения
Я считаю, что когда людям нужно получить от внешней системы буквально одну-две функции, гораздо правильнее реализовать их с помощью небольших доработок.
Кейс с платежным календарем
Например, люди хотят получить платежный календарь. В стандартных УПП или ERP есть заявки на расход денег. Они неудобные – их согласовывать неудобно, менять неудобно – но в принципе, пользоваться можно.
Но если посмотреть на платежный календарь, то им, что в УПП, что в ERP, пользоваться вообще невозможно
Если люди четко говорят: «Нам нужен только платежный календарь, остальное у нас нормально» – я им делаю платежный календарь. Тогда у них появляется та самая система управления финансами, которая им нужна: с drag-and-drop, с расчетом динамических остатков и так далее. Это не проблема – красивый платежный календарь можно сделать за пару дней.
Кейс с CRM
Или другой пример: компании нужна конкретная функция CRM – автоматическая загрузка переписки с клиентами в базу или интеграция с телефонией Mango. Но когда он приходит в компанию-интегратор и говорит: «Нам нужно, чтобы в систему почта грузилась, и была связка с телефонией», менеджер часто отвечает: «Вам нужна полноценная CRM!»
Дальше клиента ведут в другую комнату и начинают уговаривать: «Почему ты хочешь работать только с телефонией и с почтой? А давай тебе все по полной сделаем – проект!»
Если клиент здравомыслящий, либо ему повезло встретить честного специалиста, который говорит: «Не надо тебе CRM, не связывайся ты с ним. Давай сделаем тебе вот это и это, и у тебя будет все хорошо» – тогда клиенту повезло. Но пока клиент до такого специалиста дойдет, он уже потеряет желание что-то дорабатывать.
Хочу привести еще несколько примеров, хотя мысль, наверное, уже понятна.
Кейсы с BI
Сейчас BI на слуху, особенно после того как наша дорогая любимая фирма «1С» выпустила инструмент 1С:Аналитика. Я им пользовался, он прикольный. Еще есть Power BI, он тоже никуда не делся. Но в реальной практике внедрение BI обычно начинается с одного из двух вариантов:
-
Первый вариант: у нас висит телевизор, и мы хотим вывести показатели на него.
-
Второй вариант: директор хочет раз в день получать информацию в понятном ему виде: сколько у него денег, сколько за вчерашний день было продаж, или какой-то план-факт, процент выполнения плана.
В этот момент ему говорят: «О, так здесь BI-система нужна!» И начинается масштабное внедрение.
А сейчас BI-систем пруд пруди. Кроме этого, есть системы, у которых в названии нет BI, но из них можно сделать BI.
-
Например, можно организовать дешевый BI через Excel и PowerPoint. Нарисовать диаграмму в PowerPoint, привязать ее к данным из Excel, а в 1С написать обработку, которая будет складывать данные в этот Excel – вот вам и BI-система. Ее можно смело открывать на телевизоре, потому что телевизор умеет открывать PowerPoint, или сохранить в HTML с автообновлением. И телевизор будет показывать те показатели, которые нужны.
-
Или можно вывести директору сообщение о том, сколько у него денег и сколько у него продаж через Telegram. Мы можем в Telegram отправлять все что угодно. Мы можем картинки, тексты отправлять.
-
10 лет назад мы для организации SMS-уведомлений директору о том, сколько у него денег, покупали GSM-модуль – вставляли его в сервер, чтобы он отправлял SMS.
-
Либо отправляли отчеты по электронной почте, хотя она еще тогда в смартфоне плохо работала.
Сейчас все это не проблема. Можно эту задачу решить дешево, быстро и ровно так, как хочет клиент. Причем масштабировать такую BI-систему несложно. Чтобы вывести на второй телевизор дополнительные показатели, помимо продаж и остатка средств, достаточно создать в 1C еще одну схему компоновки, слегка ее доработать, и она будет отправлять человеку данные.
Я работал на том самом заводе, где мы директору отправляли показатели в SMS. У нас прямо в коридоре висел телевизор и показывал диаграммы. Вся автоматизация заняла один день.
Потом в качестве развлечения мы обнаружили, что в коробочном варианте «Корпоративного портала Битрикса», который мы купили и развернули у нас на сервере, есть мобильные приложения. Оказывается, если ты знаешь REST API Битрикс, то можно записывать туда любые данные из 1С практически напрямую. И прямо там на месте с помощью библиотеки D3.js построить на основе этих данных нужные графики.
Но вместо простых решений люди внедряют BI-систему. У нас в Челябинске есть клиент, с которым мы не договорились, потому что я там с программистами разговаривал. У них большой красивый модный офис. Местным программистам сказали: «Сделайте нам BI». Они позвали нас, я приехал, говорю: «Что надо показывать?» Они говорят, что у них телевизор висит, и на нем надо показывать показатели продаж по регионам. Все данные есть. Я говорю: «Давайте сделаем». Ребята говорят: «Нет, мы хотим рассмотреть вариант с Power BI. Мы уже лицензии посчитали, но Power BI данные берет через OData, а OData нам не подходит, она слишком медленно данные выдаёт». В общем, мы с ними не договорились. Я ушел, а парни стали внедрять BI-систему. Не знаю, сколько денег они потратили и какую, в итоге, BI-систему внедрили.
Даже 1С:Аналитика – она, в принципе, прикольная. Я, кстати, тому самому клиенту, который Power BI себе хотел, 1С:Аналитику тоже показывал. Он отказался, потому что там OData. Чем ему эта OData не понравилась? Непонятно.
Кейсы с MDM
Еще один пример – MDM.
Честно говоря, я никогда не видел работающей MDM-системы – чтобы в ней работали те функции, которые изначально заложены в саму идею систем управления НСИ.
Самый распространенный пример – это вывод номенклатуры из оборота. В любой типовой конфигурации у вас есть номенклатура. Если предприятие активно занимается НИОКРом, то некоторые номенклатуры иногда выходят из оборота – их перестают производить, их не надо продавать.
Попробуйте в УПП или в ERP вывести номенклатуру из оборота. Нет такой функции вообще! Без доработки нет возможности запретить отгружать или покупать эту номенклатуру. Если клиент обращается с такой задачей, она решается за два часа с помощью программирования: можно просто встроить расширение, которое задает ограничение, типа «вот это бери, а вот это не бери». Но люди от такого запроса начинают внедрять MDM-систему.
А есть такие, у которых фантазия разыгрывается, они говорят: «Так, а дело же не только в номенклатуре! А у нас ведь еще склады, бывают, из оборота выходят. Был у нас склад какой-нибудь консигнационный в Сургуте, а больше его нет!» Или меняется структура подразделений – есть предприятия, которые практически каждый год полностью меняют оргструктуру, меняя названия подразделений. И что с этим делать в типовой конфигурации – непонятно. Они тоже хотят внедрять себе MDM-систему.
Есть предприятия, которые хотят просто синхронизировать номенклатуру между двумя базами. Для этого необязательно внедрять полноценную MDM-систему – достаточно просто взять из ее методологии нужный инструмент, например, MDM-ключ.
Или можно назначить сотрудника, который будет аккуратно вносить данные, и организовать систему обмена типа Master-Slave. Это быстро, несложно и недорого. Например, сейчас на предприятии настроен полный обмен в обе стороны. Но если в одной базе данные вводит ответственный сотрудник, то во второй базе достаточно запретить изменение номенклатуры (что займет около часа работы программиста) и организовать односторонний обмен.
Так мы получаем простую и рабочую MDM-систему – вместо того чтобы купить коробку и поставить ее в шкаф.
Вопросы и ответы
Из доклада я понял, что вы придерживаетесь принципа «бритвы Оккама» и стремитесь к упрощению. Бывали ли в вашей практике доработки, которые впоследствии усложняли обновление системы? Или такие, которые со временем были реализованы в новых версиях, из-за чего приходилось отказываться от собственных решений в пользу типовой функциональности? Или более того, вести параллельный учет – заполнять регистры из доработок и одновременно учитывать эти моменты в типовом решении?
Конечно, были. Например, мне недавно довелось «ковырять» Бухгалтерию предприятия 3.0, в которую кусками вставили «Управление холдингом». Причем ее вставили, попытались работать с этой функциональностью, у них не получилось, они начали писать все то же самое свое, написали – тоже не подошло. Сейчас покупают MDM.
По поводу того, что мы что-то делаем, а потом в типовой конфигурации появляется дублирующие – такое редко. Бывает, клиенту нужно, чтобы у него функциональность появилась срочно, а ты точно знаешь, что она будет в типовой конфигурации, но когда – неизвестно. В таких случаях я клиенту честно говорю: «Можешь ждать, а можешь – нет».
В ERP есть функциональность, которую бессмысленно от них ждать. Например, планирование. Или управление процессами, которое там реализуется через бизнес-процессы, а не через контроль конкретных точек процесса.
У меня был шикарный кейс, когда я клиенту сказал: «Типовое планирование не решит вашу задачу». А он верил, что решит. И мы договорились, что запустим типовое планирование в ERP за его деньги, а потом переделаем все еще раз. В итоге три месяца запускали типовое, а потом переделывали. Заплатил дважды. Зато теперь мы друзья.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
