Управление проектами внедрения 1С:ERP

Проект еще не начался. Этап «пресейла»

Свое рассмотрение вопроса управления проектами 1С:ERP я начну с этапа пресейла.

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

Вопрос пресейла критичен и когда вы выступаете со стороны франчайзи, и когда вы работаете в штате компании. Это – такой этап, когда вы готовитесь к началу проекта и обосновываете этот проект для заказчика (или для своего директора). Поэтому этап пресейла есть всегда. На этом этапе закладывается как раз тот фундамент, который позволит в дальнейшем говорить о том, будет ли проект успешным.

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

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

Что нужно на этапе пресейла заказчику?

• Во-первых, сейчас полностью перестала продаваться отдельная учетная составляющая – учет и технические знания. На слайде я написал, что технари больше не продаются. Это сейчас особенно отчетливо видно в случае комплексных проектов. Что продается?
  • Продаются бизнес-навыки того человека, который себя позиционирует как руководитель проекта.
  • Продается его понимание бизнеса.
• Когда мы говорим о больших проектах, ситуация выглядит следующим образом – у собственника бизнеса ( генерального директора, того, кто будет инвестировать деньги) на одной чаше весов находится ваш проект стоимостью 20 млн рублей, а на другой чаше весов – новое оборудование, которое он может приобрести за эти же деньги.
  • Ему понятно, что при покупке оборудования он сможет расширить производимый ассортимент товаров, снизить затраты на производство. Ему понятна та доходная часть, которая будет у него после того, как он запустит это оборудование в работу.
  • А в случае проекта автоматизации – непонятно, каким образом он отобьет эти 20 миллионов и как эти инвестиции позволят ему что-то сэкономить (увеличить объемы продаж, оборачиваемость товаров, снизить какие-нибудь запасы и т.д.). Это все человеку нужно рассказать и объяснить.

При продаже проекта 50% вашего успеха – это убедить заказчика в том, что он получит бизнес-выгоды. Например, вы говорите: «заплатите нам сейчас 20 миллионов рублей, а через год вы получите экономию в 50 миллионов».

• Следующие 50% от продажи будут зависеть от того, сможете ли вы заказчику доказать, что он через год реально получит 50 миллионов экономии. Это уже не маркетинг. Люди, которые являются заказчиками таких проектов, хорошо разбираются в бизнесе. Поэтому вы должны:
  • Провести анализ:
    • Финансового состояния предприятия;
    • Того, как управляются запасы;
    • Того, как работает система планирования.
  • На основании этих данных сформировать предложения по улучшению ситуации.
  • И донести свои выводы до заказчика на простом, человеческом пользовательском языке.
• Важна консалтинговая составляющая всего этого процесса. Если вы умеете проводить консалтинг, вы продадите такой большой проект. Иначе вас просто не услышат, какой бы хороший технарь вы ни были. Люди просто не понимают, когда им начинают рассказывать о том, что у них будет хорошая красивая система и пр. Все это сразу отметается. За такие деньги коробку никто не покупает.

Это было о том, что нужно заказчику.

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

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

Переход на новую систему – это всегда небольшая (а иногда и большая) революция. Люди будут прибегать к вам с безумным видом и кричать о том, что раньше все было лучше, а теперь все сломалось и ваша система негодная. Только если у вас будет светлая идея о том, что ваш проект сможет что-то серьезно улучшить в бизнесе, вы сумеете довести этот проект до результата. У нас есть несколько проектов, которые были успешны именно в таком аспекте. Они были нацелены как раз на то, чтобы руководитель проекта изначально нашел эту бизнес-составляющую и всячески ее продвигал и продавал.

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

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

Для чего я все это рассказываю? Я видел очень много руководителей проектов, которые на этом «выгорали». Они на таких «безнадежных», с моей точки зрения, проектах ставили для себя какие-то технические задачи – внедрить то, се. Все это не «взлетало», они расстраивались, заваливали проект, меняли свою сферу деятельности и все заканчивалось плохо – и для проекта в целом, и для них тоже.

На таких «безнадежных» проектах надо просто сразу понимать, чего вы хотите:

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

Этап 0. Организуем процесс работ

Следующий этап – когда проект еще не начался, но вы уже заключили договор (или уже есть некая договоренность с руководителем предприятия о том, что проект будет запущен).

Здесь есть организационная составляющая, та самая бюрократия, про которую многие ИТ-шники забывают. Я сам ИТ-шник и я хорошо это знаю по себе – кажется, что нужно уже начинать что-то автоматизировать, внедрять, куда-то бежать, что-то писать.

Бюрократия – это достаточно важная вещь и с точки зрения не-ИТ-шника она зачастую бывает даже важнее технической составляющей.

До начала проекта нужно сделать очень многое:

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

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

У меня есть несколько советов, которые могут быть достаточно важными – по крайней мере, для меня они были важными.

• Первый совет. На большом проекте зачастую приходится оформлять и согласовывать много документов, знакомить людей с ними. Если это делать на бумаге, то в результате вы потратите много времени. Поэтому я сейчас во все договоры (меня научили умные люди) вписываю, что официальным каналом обмена документами по данному договору является такой-то e-mail отправителя и такой-то e-mail получателя. С точки зрения юриспруденции сейчас электронная переписка приравнивается к бумажным делам, поэтому, если будут возникать какие-то конфликты вплоть до судебных разбирательств, этот e-mail позволит вам доказать, что вы отправляли документы оперативно, а заказчик их рассмотрение задерживал. И вообще, это позволит вам сэкономить время текущей работы. Вписывайте e-mail в договор – это работает, проверено на деле.
• Следующий организационный момент. Комплексные внедрения ERP – это длительные проекты. Они занимают полгода, год, два. У нас есть некоторые проекты, которые тянутся три с половиной года. Это не потому, что мы сроки просрочили, а потому, что когда запускаются очередные подсистемы, срок проекта удлиняется. На таких проектах очень важна бытовая составляющая – люди должны жить в хороших условиях.
  И если у вас есть некая команда, которая работает под вашим руководством, и вы со своими сотрудниками выезжаете куда-нибудь в Сыктывкар, ваши люди в течение этого длительного времени должны жить в человеческих условиях. У меня был один такой проект – вроде все хорошо идет и заказчик адекватный, а консультанты «отстреливаются». Один поработал неделю – попросился на другой проект, второй поработал – тоже ушел, третий – то же самое. Когда я начал разбираться, оказалось, что у них в квартире была забита канализация и им каждый вечер после работы приходилось «бороться с унитазом». Понятно, что это не способствовало рабочей обстановке. Поэтому:
  • Проверяйте, как ваши люди живут;
  • Проверяйте, как они питаются.

Если говорить о работе на территории заказчика, проверяйте, как люди обустроены у заказчика:

• Насколько у них хорошие рабочие места;
• Есть ли у них техника;
• Есть ли у них нормальный доступ в интернет;
• Удобная ли у них мебель;
• И все прочее.

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

То, о чем я рассказываю, звучит немного банально, но я сам с этим столкнулся и убедился, насколько это «переворачивает» ситуацию.

Этап 1. Проектирование системы

Все, проект начался, идет этап проектирования системы. Что здесь важно?

Мы все начинали с классического подхода, когда пишется некое ТЗ – документ, в котором перечислены технические требования и к ним написано какое-то техническое решение. Как показывает практика, такое ТЗ – ни богу, ни людям. И пользователи его не понимают, и для программистов оно недостаточно подробное, чтобы что-то по нему начать программировать.

Сейчас мы на этапе проектирования никакие ТЗ на наших проектах не пишем. Что же мы делаем? Результатом этапа проектирования являются два документа, два объекта:

• Первый – это функциональная модель. Мы устанавливаем тестовую базу и заносим в нее какие-то выборочные данные заказчика. А потом на этой реальной базе показываем заказчику, как он будет работать в системе – как будет выглядеть процесс приемки, отгрузки товара, складской учет, планирование. Люди все это видят и прикидывают, смогут они так работать или нет. В результате проще найти общий язык, договориться хотя бы на визуальном уровне:
  • Показали функциональную модель,
  • Нашли, что подходит и не подходит,
  • Зафиксировали какие-то функциональные разрывы (потребность в доработках) – про них я поговорю попозже. 
• А дальше я создаю документ «Концептуальный проект» – это функциональная модель, зафиксированная на бумаге. Там я человеческим языком (я покажу пример) описываю, как должны протекать процессы предприятия:
  • Как оформляется процесс закупки;
  • Как оформляется процесс продажи;
  • Как выглядят те или иные складские операции, производство и все прочее.

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

Что дает этот «Концептуальный проект»? Он преследует две цели:

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

Поэтому концептуальный проект пишется на пользовательском языке максимально понятно.

Здесь я привел пример оглавления концептуального проекта.

• Сначала идет описание предмета автоматизации;
• Потом описание по всем процессам, которые протекают;
• Фиксируется потребность в доработках;
• И описывается план переноса данных.

Это такой всеобъемлющий документ, в котором:

• Описана вся структура проекта;
• Все работы, которые должны быть проведены по проекту;
• И прописаны все регламенты работы пользователей.

Этап 2. Доработка типовой системы

Этап доработок. Здесь уже речь идет о том, что типовая функциональность не подошла, и нужно дорабатывать систему под новые требования, которые появились у заказчика.

На этапе доработок у нас уже в любом случае появляется техническое задание (ТЗ):

• ТЗ пишет консультант;
• В соответствии с этим ТЗ работает программист.
• И потом, когда программист закончил работу, консультант принимает работу программиста.

Но это ТЗ написано техническим языком, пользователи его не понимают. Поэтому для пользователей мы ко всем своим ТЗ дополнительно прикладываем документ под названием «Сценарий приемки». В нем опять же на пользовательском языке должно быть написано:

• Что должен пользователь делать в системе;
• Какие должны быть отклики от системы;
• Какие экранные формы у новых документов, справочников, отчетов, обработок и всего прочего.

Максимально доступно, максимально понятно для того, чтобы потом, при сдаче этой работы пользователям, можно было опереться на исходный сценарий приемки, который пользователь подписал, и сказать: «Смотрите, вы хотели, чтобы система так работала – она так работает. Если есть какие-то замечания, давайте договариваться».

На слайде приведен пример сценария приемки. Здесь:

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

Этап 3. Обучаем сотрудников

Следующий этап – это обучение сотрудников.

Когда-то достаточно давно, в 2004 году, я делал свой первый большой проект. Мы на этом проекте проводили обучение пользователей, они кивали, говорили – да, все понятно, хорошо, поехали. И в тот день, когда началась опытно-промышленная эксплуатация, я пришел на работу минут на 5 пораньше, в галстучке, с новой записной книжкой. Я думал, что это день моего триумфа – новая система запускается в работу.

Система запустилась, но оказалось, что все не работает: пользователи не знают, как вносить документы; логисты не знают, как доставлять товар; производственники не знают, как фиксировать факт отгрузки. Все пошло «комом» – этот ком катился дня три. Домой я не ездил, жил на работе, как рассказывали очевидцы, воровал колбасу с производства. Не суть важно. Важно, что после этого я понял одно – пользователи на этапе обучения не обучаются.

Здесь есть два варианта:

• Первый – это выбросить этап обучения вообще и перейти сразу к следующему этапу.
• А второй вариант – это то, что я сейчас использую.

Я на этапе обучения провожу расширенное тестирование функциональной модели.

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

Этап 4. Загрузка начальных данных

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

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

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

Этап 5. Опытно-промышленная эксплуатация

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

По моей оценке, на каждые 20 пользователей нужно иметь одного консультанта. Если у вас 100 рабочих мест, которые нужно запустить на этапе опытно-промышленной эксплуатации, значит, в первый месяц промышленной эксплуатации у вас должно быть 5 консультантов. Если 200 – значит, 10 консультантов.

Почему? Потому что иначе пользователи будут бежать к вам непрерывным потоком, и вы просто разорветесь и не сможете дальше переваривать все их обращения. У вас проект просто свернется в коллапс. Поэтому людей должно быть достаточно. На том проекте, про который я рассказывал, людей у нас было недостаточно. Там автоматизировалось порядка 150 рабочих мест, а нас было всего четыре человека – три программиста-консультанта и я. Нас просто физически не хватало, чтобы обработать все запросы.

Если клиент сложный, то консультантов нужно больше. Сложный клиент – это:

• Немотивированный клиент, который не хочет переходить на новую систему;
• Пожилые люди.

Мы занимаемся проектами ОПК (оборонка), и там достаточно много предприятий, где работают люди в возрасте 60-70 лет. Они там «живут» еще со времен Советского Союза. С такими людьми приходится проводить достаточно много времени. Им нужно рассказывать, как пользоваться компьютером, мышкой и всем прочим.

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

Если вы директор по ИТ (или начальник отдела ИТ) и у вас начинается опытно-промышленная эксплуатация:

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

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

• Это делают и сами пользователи – в Redmine есть компоненты, которые позволяют автоматизировать создание инцидентов через электронную почту.
• И консультанты у меня в обязательном порядке все обращения вносят в систему.

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

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

И вы уже с этими конкретными проблемами начинаете работать:

• Инициируете задачи на изменение функциональности;
• Решаете вопрос увеличения бюджета;
• Или просто исправляете какую-то ошибку, если это ваша ошибка.

Без системы управления инцидентами в больших проектах делать нечего. Я на системе управления инцидентами «вытянул» два проекта – просто внедрил на предприятии систему, куда люди стали регистрировать ошибки и сразу стало понятно, что это просто пользователи расслабились, не хотели делать то, что им говорили.

Роли сотрудников на проекте

Немного лирики. Что я требую от своей команды и от самого себя на проекте?

• Руководитель проекта – это в первую очередь организатор проекта. Я пришел в руководители из программистов, для меня зона комфорта – это конфигуратор. Но если я сажусь в конфигуратор и начинаю что-то писать, значит, мой проект уже живет своей жизнью, а я зашел в свою «нору» и там сижу. Этого допускать нельзя, потому что вы, как организатор, должны в обязательном порядке процессом управлять и организовывать его. А если вы начнете писать код, то проектом будет управлять кто-то другой.
• Что я пытаюсь донести до консультантов? Очень многие консультанты «болеют» следующим – они говорят, что «пользователи дураки». Тут у меня аргумент всегда такой – если пользователи дураки, тебя-то, умного, зачем сюда взяли? Чтобы ты людей научил. Учи людей. Твоя задача – выйти за забор «пользователи дураки» и научить их работать с системой. Нужно донести до консультантов, что это – та работа, для которой их и взяли.
• Про программистов – у нас программисты всегда работают в «черном ящике». Им консультанты задачу поставили и они над этой задачей работают. В такой ситуации у человека очень высок риск потери внутренней мотивации. Он не понимает – то ли он делает, или не то? Хорошо ли это, или плохо? Чтобы поддерживать у программиста определенный уровень внутренней мотивации, ему необходима обратная связь, особенно, когда он работает через консультанта. Ему нужно говорить, что то, что он делает – это пользователям нужно, это у пользователей работает. Если вы не будете им этого говорить, программисты у вас начнут косячить, и вы их просто начнете терять – это из практики.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 COMMUNITY. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.