Обычно мы рассказываем о том, как все замечательно, как все хорошо и здорово. На самом деле практика показывает, что зачастую получается не все. По крайней мере, не с первого раза.
Последние лет 15 я рассказываю о том, как сделать успешный проект, какие есть сложности, какие грабли. В статье еще раз посмотрим на эти проблемы.
Тема сложная. Особенно сейчас, в период охлаждения экономики, когда каждый проект является для нас крайне ценным, и успех этого проекта вносит действительно большой вклад в развитие наших компетенций.
Как понять риски еще на старте проекта
Даже на этапе, когда мы только начинаем проект, мы можем понять, насколько он будет либо не будет успешен.
Есть разные сегменты рынка, есть разные по масштабу компании. Так исторически случилось, что на решениях фирмы 1С, на ERP-решениях, мы покрываем большую часть рынка в целом. Это и средние компании, и крупные компании, теперь уже крупнейшие компании. И особенности каждого сегмента, безусловно, дают о себе знать.
Если мы говорим о крупнейших и крупных компаниях, то здесь больше работа именно с корпоративным заказчиком, понимание внутренней политики, архитектуры коммуникации. Если мы говорим, например, про средние компании, где можно пожать руку собственнику, то здесь больше можно смотреть именно тематику работы на результат.
Но очень важно понять, когда мы только начинаем проект: ради чего мы этот проект делаем?
Бывает так, что управляющая компания куда-нибудь на завод спускает новые требования: «Ребята, давайте внедрять новые технологии управления для контроля, для планирования, для организации работы». Но на местах есть сопротивление: такая система там не нужна, это дополнительная прозрачность. И мы понимаем, насколько у этого проекта появляются дополнительные риски.
Бывает так, что мы видим: ставят осознанные цели. Да, действительно есть проблема, а проблему можно решить за счет правильной организации, правильного управления, внедрения четкой формализованной системы. И здесь риски сильно уменьшаются.
Поэтому даже на старте проекта можно дать некую внутреннюю оценку: насколько этот проект будет для вас сложен и какой характер проблем потенциально может быть: это технические проблемы, организационные проблемы или проблемы команды в целом.
Мы в том числе анализировали проблематику не только российского рынка, а рынка ERP в целом по миру. И проблематика на самом деле сходная. У нас какой-то уникальной картинки нет. Мы точно так же идем в тренде со всеми ведущими вендорами, с ведущими интеграторами в мировом масштабе.
Как правило, блок технологических проблем менее значим. С точки зрения проблематики больше именно организационная часть: процессы, организация команды и ключевая роль руководителя проекта. Это человек, который может аккумулировать в себе очень многие вещи и решать те проблемы, с которыми мы сталкиваемся.
Готовность компании к изменениям
Прежде всего нужно понять, насколько компания готова к изменениям, когда мы идем в большой глобальный проект.
Если мы видим, что компания не готова меняться, если мы считаем, что текущее мироустройство компании в виде процессов, текущее устройство в виде понимания, какой должна быть информационная система, должно остаться как есть, то здесь потенциально, безусловно, появляются риски.
Это очень большие риски. К сожалению, мы должны будем очень многое переписать и сделать какого-то уникального монстра-мутанта из типового продукта. И понятно, какие будут проблемы дальше в целом – в части владения системой и сопровождения.
Поэтому на первом этапе понимания, насколько компания готова к изменениям, нужно попробовать показать свою позицию не только как специалиста по IT, специалиста по цифре, но прежде всего показать компетенции именно в части управления процессами, понимания бизнеса. То есть разговаривать с бизнесом на одном языке.
И здесь возникает очень важный момент: любая информационная система – самая прекрасная, самая совершенная, неважно, какого цвета она будет, желтая, синяя, зеленая, – это всего лишь небольшой процент общего успеха. Основной момент хранится именно в сегменте подготовки правильных процессов. Если мы правильно подготовим процессы, правильно поймем, что именно таким образом логика будет запрограммирована уже в конечном продукте, тогда мы действительно можем получить реальный успех.
Если компания готова идти в процессы, готова в это вкладываться – это еще один большой плюс. Если мы говорим: «Нет, окей, ничего другого быть не может, берем как есть», – это еще один дополнительный признак того, что в дальнейшем могут быть проблемы.
Нормативно-справочная информация
Теперь одна из самых главных глобальных проблем. 15 лет я про это рассказываю, и ничего не поменялось.
Ключевой момент: внедряя большие информационные системы, мы сталкиваемся с блоком нормативно-справочной информации. Справочник контрагентов, статьи калькуляции, спецификации, номенклатура, технологические процессы – это очень важно.
Нет ни одного красивого, успешного проекта, который не столкнулся бы с проблематикой НСИ. Это есть у всех. В разных отраслях, конечно, по-разному, в разных сегментах тоже по-разному. Но зачастую на практике случаются такие вещи, что наша компания даже не осознает проблематику в части нормативно-справочной информации, а потребитель уверен, что с НСИ у него все прекрасно.
На реальной практике мы, как вендор, всегда полагаемся на проекты, которые делают партнеры. Но при этом какие-то вещи мы делаем в том числе сами: какие-то пилотные проекты для развития типовой функциональности либо проекты, которые являются критически важными для развития как системы, так и сегмента ERP в целом. И на наших проектах мы тоже столкнулись с проблемой НСИ. Коллеги были уверены, что все у них прекрасно, что все здорово, что все из бумаги уже в цифре, что все данные прекрасны. Но после того, как мы загрузили данные в систему и построили производственный план, коллеги сказали: «А вы знаете, вы сделали совершенно не то. Ваша система не работает, нам такая система не нужна. Вы посмотрите, как происходит в реальной жизни и что показывает ваша система». Это были два разных берега.
Стали детально смотреть. А проблема была не в системе. Проблема была в тех данных, которые были загружены как спецификации, как нормативы времени. И пока этот этап не пройден, зачастую есть ощущение, что с НСИ все прекрасно.
Конечно, есть случаи, когда наши уважаемые пользователи сразу говорят: «Да, у нас проблема с НСИ. Это первый этап». Мы организуем группу, которая будет заниматься нормализацией данных.
И здесь тоже есть некоторые лайфхаки, как это происходит в жизни. Безусловно, если мы говорим о большом промышленном предприятии, объем данных очень большой, и период нормализации данных может быть крайне велик. Мы можем на первом этапе подготовки данных потратить полгода, год.
Можно это распараллелить. Можно посмотреть на те данные, например по спецификациям, номенклатурам, контрагентам, которые есть у нас на ближайший период – например, на период промышленной эксплуатации системы, на ближайшие четыре месяца. И сделать особый упор именно на отработку этого сегмента данных. А после этого мы уже постепенно догоняем те позиции, которые потенциально могут появиться в дальнейшем. Это очень важный момент, поэтому на него стоит обратить особое внимание.
Достоверные начальные данные
Прекрасно, если мы делаем проект на предприятии, которое появилось с чистого листа – greenfield. Предприятие только начинает работать, мы открываем новое производство, открываем новый сервис и сразу вместе с компанией ставим новый программный продукт. Но это единичные случаи.
Обычно мы приходим на какую-то поляну, где есть незавершенное производство, какие-то остатки, деньги, контрагенты, клиенты – масса всего. То есть те самые достоверные начальные данные, которые мы обязательно должны загрузить в систему.
И здесь возникает очень много вопросов: где взять те самые достоверные данные?
Случай из нашей жизни. Мы делали один интересный пилотный проект, который был посвящен развитию ремонтного производства в ERP. Это промышленное предприятие: сложное производство, сложные изделия. Начинали мы с блока управления производством. Далее постепенно уже подключали экономические службы, подразделения, которые отвечают за ведение регламентированного учета.
Третьего января нужно переходить в опытную эксплуатацию. Нужно загрузить начальные данные: выверенные, красивые, очищенные, чтобы все было прекрасно и здорово. На момент старта в компании действовали две информационные системы. Одна информационная система была для управления производством, вторая – для поддержки ведения регламентированного учета. Две самописные системы. И там, и там были какие-то остатки. Нужно было загрузить производственный блок. Поэтому перед РП со стороны пользователя встал вопрос: откуда брать остатки? Из бухгалтерской системы или из производственной?
Естественно, долго думали и в конечном итоге приняли волевое решение: остатки должны быть загружены из бухгалтерской системы. Потому что в бухгалтерии, как всегда, порядок, там цифры, а в производстве разгильдяи, то есть явно там что-то, наверное, не так.
Загружаем данные по остаткам из бухгалтерской системы, переходим в запуск, в опытную эксплуатацию. Проходит пара-тройка недель, и получается так, что некоторые позиции, которые мы запланировали на запуск в производство, мы просто не можем запустить по причине того, что материала нет на складе. По системе этот материал есть, а реально, по факту, материала нет.
Стали разбираться. Оказывается, данные по остаткам в бухгалтерской системе в количественном выражении были немного подогнаны под денежный отчет. Прекрасно, мы допустили ошибку.
Руководитель проекта снова волевым решением говорит: «Мы допустили ошибку, мы признаем это. А теперь мы загружаем данные из производственной системы». Прекрасно, здорово. Опять потраченное время, ресурсы, деньги. Делаем то же самое. Проходит две недели – результат точно такой же.
РП приходит и говорит: «Ребята, я не знаю, что делать дальше. Где остатки взять?» Я говорю: «Смотри, мы же тебе предлагали, как нужно было сделать правильно. Нужно было просто пойти и в период новогодних праздников провести инвентаризацию, сделать нормальный пересчет, получить достоверные данные, которые затем загрузить в систему».
Они говорят: «Нет, это нужно людей привлекать в праздник, дополнительные затраты, это сложно».
Я говорю: «Смотри, мы действовали по твоему плану. Мы тебе рекомендовали, как нужно было сделать правильно. Ты первый раз сделал неправильно, не послушал нас, потом второй раз сделал неправильно».
Мы понимали, к чему это ведет. Но такие случаи тоже бывают, и зачастую переубедить человека, который принимает решение, достаточно сложно. Поэтому на такие грабли мы и наступили.
Здесь очень важный момент: когда вы загружаете те самые остатки, те самые данные, которые накоплены в старых системах, обязательно убедитесь, что они достоверны, и поймите, насколько они достоверны. Способов множество.
Вовлечение заказчика и роль команды
Мы очень часто слышим такую фразу: «Я плачу большие деньги, сделайте все красиво».
На самом деле, даже если пользователь системы, заказчик, платит большие деньги, без его вовлечения в этот проект успешного результата достичь крайне сложно.
Поэтому команда – это ключевой момент. Много раз уже об этом говорили, казалось бы, простые истины. Я 15 лет говорю, что вовлечение сотрудников компании в общую командную работу в рамках большого проекта – это один из факторов реального успеха.
И здесь возникает еще один момент: тот самый руководитель проекта, про которого я уже начал говорить, со стороны пользователя. Кто это может быть?
Как правило, назначают, например, руководителя отдела информационных технологий. Должность может называться по-разному: директор по IT, CIO, начальник отдела IT, АСУ. Суть на самом деле одна и та же.
Здесь скажу, наверное, немного грубо. Многие из этих товарищей – сисадмины-переростки. Они любят отвечать за технику, еще за что-то. А в части процессов у них компетенция чуть-чуть похуже. И здесь опять возникают проблемы.
Плюс важный момент – авторитет. Да, тебя наделили какой-то задачей, ты должен это сделать, но у тебя нет полномочий. Очень часто сталкиваемся с тем, что даже замечательный, совершенно грамотный руководитель службы IT приходит, например, к коммерческому директору и говорит: «Мне необходимо привлечь сотрудников коммерческой службы и вас лично, владельцев процессов, к задаче изучения того, что у нас есть, и выработки требований».
А он говорит: «Нет, подожди. У меня продажи, у меня поставки. Давай так: мы сейчас это все сделаем, закроем, а дальше ты к нам придешь, когда мы освободимся».
У руководителя проекта нет реального рычага влияния. Поэтому здесь очень важный момент: человек, который будет за это отвечать, должен еще и обладать полномочиями, чтобы это двигать.
Обращайте внимание на то, насколько человек, который является руководителем проекта, является им не формально, а реально на практике. Может ли он какие-то вещи делать как реальный лидер?
Коммуникации в проекте
Коммуникации в проекте – это на самом деле боль. Карты коммуникаций зачастую выстраивают очень неправильно. И даже не на технике, даже не на процессах, а просто на обычных коммуникациях проекты рушатся.
Тоже пример из жизни. Пишет нам один уважаемый IT-руководитель крупного пищевого комбината. Всегда приятно, когда пишут: «Хвалим, нравится, довольны». Но так пишут мало. Обычно пишут, когда все плохо.
В очередной раз открываю почту, смотрю письмо: «Все плохо, ваши партнеры плохие. Решение плохое».
Берем партнера, который ведет этот проект, берем руководителя со стороны предприятия, садимся за круглый стол. Говорю: «Давайте, рассказывайте, что у вас произошло».
Он говорит: «Смотрите. Мы сказали, что тот релиз, который нам передали, содержит ошибки по нашим доработкам. Мы отдали задачу и ни ответа, ни привета – ничего нет».
Руководитель со стороны партнера говорит: «Как это? Мы все взяли, мы все сделали, вам передали, а вы не тестируете, и от вас нет привета».
На самом деле все было очень просто. Карта коммуникации, которая была выстроена, была завязана на обычную почту и на обычного человека. А этот человек неожиданно ушел в декрет. И все. Все забыли.
Реально коммуникации между исполнителем и подрядчиком были выстроены на почте человека, который ушел в декрет. Те все сделали, но никто не отправил письмо о том, что все сделали: смотрите и тестируйте. Проходит месяц. И никто не пробовал включить какую-то эскалацию или еще что-то.
И таких примеров, когда в рамках реального проекта происходит такое безобразие, много. При всем том, что мы говорим: проектные технологии, карты коммуникаций, организация, специальные инструменты, СППР и другое. Ничего нет. Реальная практика жизни.
Казалось бы, уже 2026 год, и, наверное, у всех это есть. Да ничего подобного. Поэтому на коммуникации внутри больших проектов обязательно обращайте внимание. Это очень важно.
Риски и план Б
Руководитель проекта при внедрении больших систем, как правило, не рассматривает риски. Говорит: «Ребята, смотрите, есть план, по этому плану мы действуем».
Но если вдруг что-то где-то пойдет не так, плана Б у него нет.
Мы тоже с этим сталкивались даже на примере той же самой НСИ, раз уж мы про нее уже вспомнили. Был реальный проект. Заказчик взял на себя задачу подготовки НСИ. Естественно, в срок они ее не выполнили, и дальше двигаться уже нельзя.
Руководитель проекта со стороны исполнителя ставит вопрос: «А что делать дальше? Мы снимаем команду, уезжаем, приедем к вам через полгода?» Не было понимания, что это риск и должен быть какой-то план Б. Если не будет НСИ в таком виде, что мы будем делать дальше?
Хороший руководитель проекта – это не просто человек, который руководит коллективом, выстраивает какие-то коммуникации. Это человек, который может чувствовать проблематику на уровне своего ощущения и компетенции: вот здесь могут быть реальные проблемы. На уровне опыта.
Это очень важный момент. Руководитель проекта должен работать еще и с рисками.
Предпроектное обследование
Предпроектное обследование – это прекрасная вещь. Здесь тоже очень много интересных проектов.
Реальный проект. Крупное опытное производство делает очень интересную продукцию.
Что происходит? Первый этап: мы будем заниматься обследованием. Обследование длилось ровно год. Просто занимались обследованием, ничего не делали, рисовали схемки, еще что-то, итерационно, например: «Вы сделали не по тому стандарту, который мы заложили. У вас неправильная нумерация». Люди очень формально к этому относились.
За год, пока они описывали какие-то процессы, уже все изменилось. И когда пришли к этапу, когда уже нужно все воплощать в железе, все процессы изменились. И говорят: «А теперь давайте мы еще снова на годик будем заниматься вот этим делом». А где бы на это еще взять деньги? Отлично, деньги закончились.
Поэтому здесь очень важный момент: предпроектное обследование должно иметь некую золотую середину. Нельзя его не делать, но нельзя очень глубоко уходить в бюрократию. Бюрократия – это действительно зло.
Здесь нужно понимание того, каким образом вы выстроите то самое описание, которое однозначно и для вас, и для потребителя покажет реальный объект, который мы дальше уже будем воплощать в части какой-то модели.
Моделирование и прототипирование
Мы разработали различные технологии внедрения: и стандартные технологии, и технологии, основанные на Agile, и классические корпоративные технологии внедрения.
Но в рамках любой технологии очень важно моделирование, когда вы можете взять процессы, которые есть, и попробовать их просто смоделировать на типовой функциональности системы, но обязательно на реальных данных предприятия.
Вы их смоделировали, показали какие-то отклонения, и дальше уже ставите приоритеты, которые в дальнейшем могут очень сильно помочь в части максимально быстрого запуска системы в опытную эксплуатацию.
Моделирование и прототипирование именно на больших ERP-проектах на практике показывает, что это очень хороший и правильный инструмент.
Пилотные проекты
Когда мы говорим о том, что не готовы к какому-то большому проекту, мы пробуем взять маленький кусочек и провести пилотный проект. И здесь тоже может быть зло.
Мы сами с этим столкнулись. На предприятии делали производство, а после него делали уже экономику. Мы совершенно замечательно обследовали и спроектировали производственную часть, все было великолепно. Думали, что регламентированный учет будет просто как вишенка на торте.
А не тут-то было. Мы даже на уровне модели не заложили те аналитики, которые в дальнейшем будут необходимы для финансово-экономических служб. Это очень важный момент.
Пилоты должны быть максимально целостными с точки зрения модели и должны учитывать перспективу: куда мы будем двигаться дальше. Поэтому к этой теме очень важно относиться очень бережно.
Интеграции
Интеграции – еще одна очень большая проблема, когда мы недооцениваем их сложность.
Зачастую система живет не в вакууме, вокруг целый ряд других информационных систем. И мы не закладываем большие ресурсы на тематику интеграции. А это очень важно.
На уровне интеграции, на уровне обмена данными возникают очень большие проблемы. И они больше не технические, а именно организационно-логические: когда мы должны иметь правильную перекладку данных, трансформацию данных, проверку целостности.
Поэтому обязательно обращайте внимание на тематику интеграций.
Доработки и типовая функциональность
Еще одна проблема проектов – когда пытаются максимально удовлетворить все потребности, не поняв, каким образом при помощи типовой системы эти требования могут быть закрыты.
Мы говорим: «Окей, ребята, у нас есть чудные инструменты. На 1С писать быстро, прекрасно. У нас есть конфигуратор, у нас есть EDT. Мы вам напрограммируем все, что вы хотите».
Очень сложный момент. Поэтому здесь обязательно десять раз попробуйте смоделировать реализацию потребностей бизнеса на той функциональности, которая есть. Попробуйте показать бизнесу, что, возможно, где-то можно немного изменить процесс. Не менять точку входа и точку выхода, но поменять шаги процесса.
Результат будет тот же. Просто вы немного меняете шаги, но при этом не получите того самого монстра, который потом будет сопровождать очень дорого, долго и больно.
Подготовка к запуску
На этапе подготовки к запуску очень важный момент, и это тоже грабли, – процесс обучения.
Как правило, к процессу обучения персонала относятся достаточно потребительски. А это важный момент. Обучение не для галочки. Оно реально должно происходить на реальных данных. Хорошо, когда это будут реальные тесты и реальная сдача экзаменов по конкретным рабочим местам.
Иначе на этапе опытной эксплуатации вы действительно можете словить то, что люди просто не знают, как это делать. Либо обучение вы проводили где-то в самом-самом начале какой-то модели, на прототипе. Поэтому на обучение обязательно обращайте внимание.
Опытная эксплуатация
По опытной эксплуатации тоже есть такая боль: очень много проектов зачастую очень долго находятся на этом этапе.
Пока мы все не сделаем идеальным, пока мы полностью не вылижем все проблемы, мы не переводим систему в промышленную эксплуатацию. На этом тратится тоже очень много времени.
Поэтому здесь делите те проблемы, которые получили на этапе опытной эксплуатации, на блокирующие и на те, которые реально можно будет реализовать уже на этапе сопровождения, на этапе развития системы.
Промышленная эксплуатация
Промышленная эксплуатация – здесь борьба с возражениями.
Человеческий фактор есть всегда. Всегда мы говорим о том, что раньше было лучше: старые системы, старые подходы работали лучше.
Поверьте, пройдет месяц-два, люди свыкнутся, и действительно те новые инструменты, которые мы сделали, покажутся удобными и интересными.
Поэтому сильно бояться критики, наверное, не нужно. Нужно здраво смотреть, насколько эта критика реально мешает работать реальным людям и мешает работать бизнесу.
Закрепление результата
Последнее – это закрепление результата, чтобы не откатиться назад и правильно организовать сопровождение системы.
Всегда задумывайтесь о том, что будет дальше. Когда вы передали систему в промышленную эксплуатацию, подумайте, как вы будете развивать систему дальше. Какими силами, какими специалистами? С привлечением внутреннего персонала, внешнего подрядчика?
И об этом нужно думать прямо на этапе, когда проект только начинается. От этого тоже очень многое зависит.
В заключение хотел бы пожелать всем успешных проектов. Наверное, какой-то серебряной пули, универсального решения не существует. Все в ваших руках, в ваших компетенциях, в любви к нашим пользователям, в любви пользователей к нам и к нашим продуктам.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
