Как продать проект в 3 раза дороже и нанести клиенту пользу, выполнив не внедрение...

О себе

С 1С я работаю уже 15-16 лет. Из них лет 7 я работал в IT-отделе в компании – крупном алкогольном дистрибьюторе. Но потом я перешел на другую сторону, на ту, где печеньки и консалтинг, и начал заниматься 1С со стороны внедренческой компании. Последние годы мы двигаемся в сторону управленческого консалтинга, как драйвера роста и развития 1С-проектов.

С чего все начиналось

Я начну с конкретного примера, и на этом примере расскажу про наш подход, про то, как мы продаем бизнесу большие проекты. На эти продажи я смотрю с двух сторон, и буду говорить не только с точки зрения подрядчика, но и с точки зрения продажи внутренней, потому что все мы, как айтишники, проект продаем бизнесу.

Конкретный пример: к нам пришел клиент с достаточно стандартным запросом – есть много-много excel, больше 20 штук, и есть специальный человек в штате, который занимается excel и тем, чтобы переносить информацию из одних excel в другие, сверять ее и так далее. Просьба клиента: давайте приведем все в порядок, автоматизируем.

Посчитали бюджет проекта, отлично пообщались на пресейле, клиенту все понравилось. Он ушел думать. Мы в бюджет попали, попали в ожидания, но клиент ушел думать и долго не возвращался. Поскольку у нас был потом шанс продолжить с ним работу, мы узнали, в чем, собственно говоря, было дело. А дело было вот в чем: у клиента есть неудачный опыт автоматизации. Такой опыт есть практически у любого бизнеса: у всех что-то не взлетало и когда-нибудь не получалось. Поэтому он, во-первых, не уверен в себе, не уверен в том, что он сможет поставить задачи правильно. Во-вторых, он понимает, что даже если он правильно поставит задачу, правильно все расскажет, не факт, что айтишники поймут его правильно. И наконец, даже если его поймут правильно, не факт, что сделают то, что нужно. В итоге бизнес боится IT-службы, причем неважно – это внутренний отдел или подрядчик со стороны. Бизнес боится IT. Он доверяет ему самое ценное - нервную систему своей компании, учетную систему, в которой он считает деньги.

Почему получается плохо и как все исправить?

Я придумал небольшой график.

На слайде – бизнес и его собственник – часто он же генеральный директор. И он его развивает. Каждый день, каждую неделю, каждый месяц что-то меняется: появляются новые направления, новые отделы, что-то реформируется, новые продукты выходят на рынок. В какой-то момент происходит знакомство с автоматизаторами или внутренняя IT-служба приходит с идеей что-то автоматизировать.

Возьмем вариант идеальный – автоматизаторы классные, они все делают хорошо, как надо: они начали бизнес описывать, они его описали, в каком-то виде зафиксировали все. ТЗ, функциональные требования, моделирование – не важно, какой документ вы делаете. В какой-то момент все зафиксировано. Это на слайде вторая точка – «Правильное ТЗ «в моменте». Дальше IT-служба уходит разрабатывать систему, готовить пользовательские инструкции, загружать данные, то есть готовится к важному моменту – к моменту запуска и внедрения.

А что происходит с бизнесом? Бизнес дальше идет, он развивается, он меняется. И получается, когда мы приходим с системой, она не совсем похожа на то, что на данный момент клиент ожидает и хочет видеть. Мы всегда строим лайнер на лету. Наша проблема заключается в том, что мы должны перебрать двигатель автомобиля в то время, когда он, не останавливаясь, куда-то едет. Соответственно, мы имеем дело (мы – это и внешний подрядчик и внутренняя служба, которая занимается автоматизацией) не с автоматизацией, не с внедрением учетной системы, какой бы то ни было, мы имеем дело с проектом организационных изменений.

Организационные изменения происходят в бизнесе постоянно, всегда. И остановить это нельзя. Если они остановятся, значит, скорее всего, бизнес уже мертвый, а трупом заниматься неинтересно. Но раз это нельзя остановить, значит, надо на какое-то время возглавить. Нужно относиться к проекту, как к проекту организационных изменений, частью которого является внедрение инструментария.

О том, что происходит в проекте организационных изменений, написано много книжек, я не буду детально вникать. Но происходит изменение хода процессов, а иногда и самой оргструктуры компании. Происходит перераспределение задач между ролями внутри бизнеса, между должностями, иногда и изменения должностей тоже. Происходит обучение людей новым бизнес-функциям, которые они теперь будут выполнять. А уже потом обучение 1С. Изменение привычных подходов к работе, обнаружение, устранение и отдаление от проекта саботажников (почему они саботажники сейчас к этому подойдем). И в конце – внедрение учетной системы, как инструмента, который дает возможность эти изменения поддерживать.

1С-проект очень часто пропускает все пункты и идет к внедрению учетной системы. В результате мы многое теряем.

Вернемся к людям, к саботажникам. Почему они саботируют, почему люди сопротивляются изменениям? Почему люди хотят ничего не менять? Кто-то опасается, что не справится, покажет свою некомпетентность. Кто-то реально что-то скрывает и не хочет, чтобы это было видно, понимая, что прозрачность учета вытащит это наружу. Кто-то боится дополнительного объема работы. И самое главное – пользователю и так хорошо, он ничего не хочет, у него все нормально, ему ваш проект не нужен.

Чтобы запустить проект организационных изменений в компании, нужно собрать команду единомышленников. Не зависимо от того, внутри компании вы находитесь или пришли снаружи, вам нужно сформировать единую команду, в которую входят ключевые заказчики, ключевые представители подразделений и команда проекта, команда айтишников, которые будут работать, бизнес-аналитиков, менеджеров проекта, возможно, понадобятся ведущие разработчики.

Нужно сформировать цели изменений и помочь каждому из этой команды понять, что именно он получит от этого проекта. Что получит компания – понятно, что получит бизнес – понятно, иначе бы собственник не инвестировал в это деньги, если бы ему было непонятно. А что получит руководитель отдела продаж, финансовый директор или другие люди от этого проекта? Нужно помочь им понять, найти их выгоды, что у них станет лучше, после того, как проект будет запущен. И тогда они вместе с вами будут соавторами изменений, а не вашими противниками.

Естественно, нужно обеспечить совместную разработку изменений. Даже если участие пользователей не очень нужно, и вы без них можете все хорошо описать и нарисовать, их участие необходимо, чтобы они поняли, что с ними советуются, что это они все придумали, это они все процессы нарисовали, а не кто-то пришел и им их принес. А раз они это все нарисовали, значит, сопротивление будет меньше, когда все будет запускаться.

В любом проекте организационных изменений мы всегда говорим о том, что самое важное – это железная воля руководства. Без железной воли собственника и топ-менеджмента проект не взлетит. Неважно как хорошо все устроено, как классно работает проектное управление, насколько четкие регламенты, какой замечательный был устав проекта. Если железной воли менеджмента нет, проект не пойдет до конца. Где-то он встанет. Либо это будет очень больно.

Когда организационные изменения не нужны?

Весь мой доклад про организационные изменения, которые нужно продавать бизнесу и про которые бизнесу необходимо говорить. А всегда ли нужны организационные изменения? На самом деле, конечно, нет. Есть достаточно много случаев, когда нет про это речи:

• когда нужно решить техническую задачу – простую и конкретную. Например, что-то перенести, интегрировать и так далее;
• когда ничего не поменяется для пользователя, а меняются какие-то внутренние алгоритмы, но с точки зрения сотрудников ничего не изменится: как раньше работали, так и будут работать;
• когда внедряется полностью типовой программный продукт на регламентированную сферу;
• ну и наконец, если у нас идеальная компания: есть описанные бизнес-процессы, описанный функционал подразделений, актуальная структура, люди по этим бизнес-процессам, по своим регламентам реально работают, и для счастья им не хватает всего лишь системы, в которую бы они все заводили. Я таких не видел, может быть, они есть. Если найдется такая фантастическая организация, это просто рай для любого 1Сника, где все работает, не хватает только 1С.

Как осуществлять управленческий консалтинг?

Для того чтобы провести все организационные изменения, надо понять, что мы собственно меняем и как. То есть нам надо понять, как работает бизнес. Поэтому мы говорим о том, что мы не про 1С, мы про управленческий консалтинг. Мы занимаемся консалтингом, мы партнер бизнеса, который знает возможности IT-систем и помогает бизнесу эти возможности использовать. И не просто помогает, а идет немного впереди, рассказывает о том, что еще можно будет сделать завтра для того, чтобы бизнесу было лучше, чтобы он мог развиваться.

Ключевой вопрос, который зачастую задает собственник или менеджмент: «Мы что сами не знаем, как наш бизнес работает? Зачем нам какое-то обследование, какие-то там вопросы?»

Нет! Бизнес не знает, как он работает. Как работают компании? Они находятся в сфере коллективного бессознательного. Это какие-то выученные практики и совсем не факт, что если взять 10 человек из одного и того же отдела, один и тот же процесс они опишут одинаково. И если на сессиях, где будут описываться процессы, будет присутствовать, например, генеральный директор, скорее всего, он узнает много нового и интересного о том, как на самом деле работают сотрудники. Поэтому все надо выявлять и описывать.

Как проходит бизнес-обследование?

Как мы понимаем точку, откуда мы выходим, и куда будем идти? Мы обязательно знакомимся с собственниками и их реальными потребностями. Реальными – потому что нет реальной потребности «нам нужно внедрить систему 1С:ERP, документооборот». Нет такой потребности, она не существует, никому это не надо. Если бы бизнес мог развиваться, принимать управленческие решения без учетной системы, он бы это делал. Надо понимать, что это просто затраты. Реальные потребности – это какая-то боль, которую нужно решить. Поэтому мы знакомимся с собственниками и задаем им очень неприятные вопросы. В первую очередь, это вопросы про то, понимают ли они, как будет больно, понимают ли они, как все будет идти тяжело, готовы ли они расстаться с ключевыми сотрудниками, если сейчас начнутся бунты и увольнения, готовы ли они перестраивать свою компанию. И если мы видим, что этой готовности нет, скорее всего, мы в этот проект не войдём.

Что делать, если вы внутри бизнеса и вы понимаете, что нет такой готовности у нанявших вас руководителей? Есть два варианта: либо менять работу, либо просто решать технические задачи и не браться ни за какие организационные изменения.

Дальше мы готовим гипотезу. Гипотеза – это то, как данная компания должна работать в некоем идеальном, оптимальном варианте. Мы не ходим и никого не спрашиваем, расскажите, пожалуйста, как вы работаете, чтобы потом какую-нибудь ерунду записать и автоматизировать. Мы думаем о том, как эта компания должна работать на самом деле, изучаем лучшие практики других компаний, работающих в этой сфере, читаем отраслевые журналы, статьи, если есть возможность, находим экспертов из аналогичных компаний гораздо большего уровня, чтобы с ними пообщаться и узнать, как они решают такие задачи.

С этой гипотезой мы приходим к заказчику, делаем интервью с ключевыми сотрудниками и руководителями. Подготовка, подготовка и подготовка. Самое важное – это много подготовки. Мы должны задавать конкретные вопросы, потому что есть конкретные вещи, которые мы хотим выяснить. Начать надо с того, что расслабить и расположить человека. Естественно сказать, что это не допрос, мы просто сейчас хотим поговорить, как вы работаете. Обязательно активное слушание – можно и нужно говорить в беседе с заказчиком «Да! Да!», «Это очень интересно!», «Ух ты!»...

Есть люди, из которых надо выковыривать информацию, потому что они не могут ничего сказать, а есть люди, которые, наоборот, стоит им только открыть рот, и они начинают рассказывать обо всем и уходят куда-то очень далеко. Поэтому у нас должен быть план интервью, в рамках которого мы их держим и не даем от него отступать.

И наконец, маленькая полезная штука – метод  Коломбо. Есть, как правило, один неприятный вопрос, который нужно задать, один вопрос, на который с большой вероятностью соврет ваш визави, потому что это касается каких-то тонких материй для него. Этот вопрос мы не задаем в ходе интервью. Мы интервью заканчиваем, благодарим человека за беседу, за сотрудничество. Мы закрываем ноутбуки, расходимся. И когда ваш собеседник уже в дверях, надо сказать: «Ой, подождите, еще один есть вопросик маленький, расскажите вот про это еще, пожалуйста, я забыл совсем». Помните, как это делал этот человек в плаще?

В этот момент человек уже не чувствует, что он на интервью находится, он расслабился, для него этап допроса закончился, он находится в другом контексте. И он может сказать ту правду, которую он бы не сказал, пока вы его опрашиваете по схеме с какой-то тетрадкой.

На выходе из обследования мы готовим отчет. Он большой, я не буду его вам показывать, рассказывать. Можно будет зайти к нам в соцсети и там скачать шаблон отчета.

Как подобрать консультанта?

Что делать дальше? Понятно, что для такой работы нужен хороший консультант: аналитик или управленческий консультант. Как его найти или воспитать? Воспитать внутри управленческого консультанта сложно. Для этого нужен большой опыт, всякие образовательные курсы и так далее. Можно попробовать его найти. Когда вы будете его искать, важно:

1. У него должен быть профильный опыт в тех областях бизнеса, которыми вы занимаетесь. Лучше если не только со стороны бизнес-консалтинга, но и со стороны работы в компании внутри.
2. Он может не знать 1С, но он должен быть готов изучить его на уровне, достаточном для понимания того, как работают типовые конфигурации, те механизмы автоматизации, которые вы собственно будете внедрять. Потому что если он находится в другом контексте и мыслит другими объектами, он может в ходе беседы какую-то ерунду говорить тому, с кем он общается.
3. Самое важное – когда вы с управленческим консультантом общаетесь в кафе за чашкой чая или на собеседовании, вы должны понимать, что с одной стороны, у него огромный мозг и он гений, он знает все и он очень умный. Но с другой стороны вам должно быть с ним легко, комфортно и приятно общаться. Он не должен давить на вас своим мозгом и интеллектом. Потому что если он вас давит, то он будет также давить всех, с кем разговаривает. Непроизвольно. И он также на интервью, на всем бизнес-обследовании будет пугать пользователей, пугать руководителей отделов. Это не очень конструктивно. Но нужно нанимать такого человека. Это, наверное, дорого, но его надо искать и пытаться адаптировать. Если речь идет про внутренний проект, скорее всего, нет смысла брать такого человека в штат, да он, наверное, и не пойдет. Но есть смысл найти и привлечь его к проектной работе, чтобы он ваш бизнес обследовал и помог вам с организационными изменениями, а вы внедрили инструменты.

Что делать после обследования, как перейти к 1С?

В последнее время мы пытаемся заставить сотрудников компаний самих описывать процессы, хотя бы на самом высоком уровне. Понятно, что получается зачастую фигня, но зато они сами это нарисовали, а мы лишь немного дорабатываем. Да, это самые простые кубики, соединенные стрелочками, но это они нарисовали, они в этом участие приняли.

Дальше эти бизнес-процессы нужно детализировать. Детализировать до такой степени, чтобы их можно было переложить на 1С, на те конфигурации, которые вы будете внедрять: типовые и нетиповые.

Дальше мы делаем моделирование – то, как этот бизнес-процесс будет проходить в типовой конфигурации. А где типовой конфигурации нет, там будут функциональные требования или техническое задание на разработку, на доработку нового функционала.

Регламентация работы сотрудников – это важная консалтинговая часть. Не получится просто дать людям 1С, обучить их. Нужны регламенты. Раз уж вы взялись возглавить процесс организационных изменений, вам нужны и регламенты, которые покажут людям, как работать по-новому. И это тоже часть управленческого консалтинга, это не часть 1С.

Организационные изменения нужно постоянно поддерживать. Организационные изменения не кончаются никогда, как минимум до тех пор, пока не закончится проект внедрения системы. Поэтому регулярно нужно собирать людей, рассказывать им о том, как этот проект продвигается, подтверждать их участие в проекте, чтобы они продолжали чувствовать себя вовлеченными, продолжали чувствовать себя соавторами тех изменений, которые происходят в компании. Эту рабочую группу ни в коем случае нельзя отпустить, чтобы они охладели к проекту. Потому что когда дойдет дело до внедрения учетных систем, а внедрение – это самая болезненная часть, когда, наконец, от теории все переходят к практике сопротивление возрастает моментально. И тогда именно эти люди, которых вы все это время подогревали, вовлекали, с ними работали, именно они будут проводниками положительных эмоций в сторону компании.

Какие могут быть неудачи?

Не все у нас получалось. Естественно были неудачные кейсы. Что у нас не получалось? Например, мы вошли в проект, не убедившись, что клиент готов к организационным изменениям. И теперь, как я рассказал, в самом начале мы максимально пугаем заказчика и топ-менеджмент, говорим о том, что это будет очень тяжело, очень больно, могут уходить ключевые люди, увольняться директор или бухгалтер. Мы вошли в проект без такого «пугания», и когда было бизнес-обследование, все было весело, интересно, процессы рисовали, спорили, у доски потусовались. А когда дело дошло до того, что надо готовить данные, надо принимать решение о том, как справочники в разных системах придут в единый формат, все встало. Клиент не был готов к организационным изменениям. Надо было не начинать.

Вторая большая проблема – это когда клиент время думает, что мы про 1С. Одинаково актуально и внутри, если вы IT-отдел, и если вы пришли снаружи. Вы начинаете управленческий консалтинг, процессы сейчас рисовать будете, будете планировать организационные изменения, а клиент время от времени забывает, и спрашивает: «Почему вы так много от меня хотите? Не слишком ли вы много хотите 1Сники?». Каждый раз мы возвращаем его и говорим, что мы не про 1С. Если мы будем просто из 1С, тогда давайте ТЗ, мы по ТЗ вам сделаем. Вы же результат хотите? А результат – это проект организационных изменений.

И наконец, есть такой ужасный вид клиента, который все знает сам, а до сих пор не сделал просто потому, что у него времени не хватает.

Когда не стоит пытаться делать проект организационных изменений?

Не стоит пытаться устроить организационные изменения:

• если инициатор проекта не имеет возможности и желания эти изменения проводить;
• если целью проекта не является развитие бизнеса. Казалось бы, всегда эта цель есть. Но нет. Если, например, цель проекта – распилить несколько десятков миллионов и какую-то сумму между кем-то поделить, ни про какое развитие бизнеса речи не идет в таком случае. Не нужны никакие организационные изменения, это будет геморрой, который помешает подписать нужные документы;
• если заказчик – небольшая компания. В чем проблемы с небольшими компаниями на 10 человек в штате (это условно, в маленькой компании может быть и 30 человек в штате)? Это слишком быстрые организационные изменения внутри, компания меняется еще быстрее. Вы неделю назад с ними пообщались, через неделю пришли со своими решениями, а у них за эту неделю все поменялось: они переехали в другой офис, открыли филиал, сферу деятельности поменяли. То есть нужно, чтобы компания чуть-чуть стабилизировалась;
• если в компании нет денег или у ключевых людей нет времени. И дело не только в оплате услуг, но и в том, что если у компании денег нет, это значит, что у них нет резерва, и они не смогут пережить тяжелые времена. А тяжелые времена могут настать, когда начнут уходить ключевые люди, например. Или что-то сильно начнет перестраиваться, меняться структура клиентской базы. У компании должен быть запас, компания должна прийти, когда у нее все хорошо, деньги запихивать некуда, но они понимают, что это какое-то временное состояние, которое нужно систематизировать для того, чтобы двигаться и развиваться дальше.

В самом начале я говорил про клиента, который пришел с десятками excel. Что получилось дальше? Они к нам вернулись, мы им изложили этот подход, мы рассказали про бизнес, про процессы, про выявление потребностей, про то, что мы, наверное, будем вас не автоматизировать, потому что не очень понятно, как ваши десятки excel перевести, мы будем описывать процессы, которые у вас в компании работают и, наверное, попробуем помочь вам их перестроить.

Клиент оказался рад, он именно этого и хотел, он понял, что с ним говорят на бизнес-языке, и в результате он купил проект, который стоил в 3 раза дороже по сравнению с тем бюджетом, который был изначально объявлен для 1С-проекта. Потому что проект включает в себя перестроение бизнес-процессов, разработку и внедрение новой руководящей структуры, регламентацию работы. Также по ходу дела выяснилось, что, например, нужна разработка СУП – системы управления проектами, именно регламентов управления проектами, нужна разработка системы бюджетирования, опять-таки как методологии бюджетирования. То есть в компании есть много разных задач, консалтинг никогда не заканчивается, всегда в компании есть, что улучшить. Если зайти туда грамотно, мы найдем огромный фронт работы.

Плюсы управленческого консалтинга

Есть еще несколько положительных моментов. Саботажники были найдены, пока все описывалось, регламентировалось, шла работа над бизнес-процессами. Несколько людей, которые были явно против, были от проекта отстранены. А когда дело дошло до внедрения, они к внедрению никоим образом не относились и просто физически не могли ему помешать.

Еще хочу показать такой чек-лист.

Мы собрали его на основании своего опыта. По ссылкам можно его скачать. Это наша субъективная оценка, как понять, клиент на входе готов к организационным изменениям или нет. В нем достаточно много параметров, мы их анализируем и в итоге натыкаемся на очередного клёвого клиента или не очень клёвого. Соответственно, мы эти параметры дополняем, и у нас получается такой большой-большой список, как по одной цифре понять, стоит начинать или не стоит.

На этом все. Спасибо больше за внимание.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.