Текст книги "Введение в управление проектами внедрения ERP-систем"

2.2.Тендер и участие в нем

Ну что же, решение о том, что компании нужна ERP-система, принято, начинаем выбирать саму систему и исполнителей для проекта внедрения.

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

Второй случай (нет понимания) нужно приводить к первому. Для этого нанять в штат специалиста, который понимает в автоматизации компаний, – это будущий руководитель проекта внедрения со стороны заказчика, а впоследствии руководитель группы поддержки и развития системы в компании. Вся группа, впрочем, может быть из одного этого специалиста или разрастись до целого отдела. Можно выбрать специалиста с целевыми компетенциями из текущих сотрудников и предложить сменить вид деятельности, карьеру и занять такую интересную вакантную должность. Но нужно учесть, что этот специалист должен иметь опыт или профильное образование для соответствия задачам внедрения проекта автоматизации. Итак, с помощью Интернета, знакомых коллег из других компаний отрасли получено первичное представление о мире ERP-систем: какие системы бывают, кто основные игроки на рынке (кто их производит, кто внедряет). Например, по 1С: ERP много информации предоставлено в открытом доступе на официальном сайте продукта http://v8.1c.ru/erp/. Составляется шорт-лист систем и их потенциальных поставщиков. Компании, туда попавшие, могут быть как крупными, известными на рынке, так и мелкими, но по рекомендации знакомых.

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

Далее нужно составить документ (несколько документов) из серии RFx:

● RFI – запрос информации (англ. Request For Information);

● RFP – запрос на предложение (англ. Request For Proposal);

● RFQ – запрос о цене (разрабатываемой системы) (англ. Request For Quotation).

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

Цель документа – собрать письменную информацию о возможностях различных поставщиков. Как правило, запрос предполагает заполнение таблички опросника в определенном формате, благодаря чему ответы от разных поставщиков по шаблону могут использоваться для сравнения информации. RFI редко является заключительным этапом, часто используется в комбинации с запросом предложения (RFP) и запросом цены (RFQ).

Компании, проявившие интерес, и составят круг участников тендера на проект автоматизации.

Если уже ясно, какая ERP-система нужна (а такое бывает, т. к. определяется, например, стоимостью самой системы или поддержкой отраслевой специфики), то выбор самой системы уже ясен, и проводится выбор исполнителя для проекта автоматизации.

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

Как управлять рисками и бюджетом проекта, в этой книге описано для стороны исполнителя. Можно эти знания применить и для отдела внутри компании.

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

О fit-gap анализе речь пойдет в следующем разделе этой главы.

На данном этапе считаем, что такой анализ проведен, результаты получены. Что дальше?

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

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

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

До момента выбора системы такую информацию «из первых рук» можно получать на профильных мероприятиях, где доклады о ходе внедрения и интересных практических кейсах делают сами пользователи ERP-системы. Например, у «1С» такое мероприятие проходит ежегодно: «Бизнес-форум 1С: ERP» http://1c.ru/bf/. После докладов можно подойти к докладчикам и узнать подробности, договориться о визите в гости с показом системы.

2.2.2.Со стороны исполнителя

В какой-то момент приходит запрос об автоматизации от потенциального клиента. Запрос может прийти:

● на корпоративный e-mail, указанный на сайте;

● через форму обратной связи сайта;

● через знакомых;

● на личных встречах на профильных форумах и других мероприятиях (да хоть в бане у общих знакомых) вместе с вручением визитки с контактами.

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

Но чаще запрос будет неформальным письмом: «Нам нужна автоматизация, что вы можете предложить и что ваша система может?»

В предыдущем разделе книги «Со стороны заказчика» исходим из правильного подхода: RFx-документы и все такое. В этом разделе (со стороны исполнителя) будем реалистами: запрос будет не «каноническим» с высокой вероятностью. Пойдем по пессимистичному (реальному) сценарию.

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

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

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

Формулировать конкретное коммерческое предложение с суммами и сроками всего проекта пока рано. Речь идет скорее о часовых ставках и примерных «вилках» типовых проектов такого плана «от» и «до», плюс информация о ценообразовании на саму систему ERP. В описании системы может присутствовать информация о требовании к аппаратной части (серверам) для работы с пометкой, что возможны варианты в зависимости от объема данных и количества пользователей. Можно сразу предложить разные варианты поставки системы, включая облачные сервисы.

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

Ответ на RFI лучше формулировать с учетом специфики работы компании, изучив доступную информацию на сайте заказчика или по иным доступным источникам. Клиент должен увидеть понятные для себя термины и знакомые (свои родные) бизнес-процессы.

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

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

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

● менеджер, который ведет переговоры;

● руководитель проектов;

● (опционально) куратор со стороны исполнителя (обычно сам директор, участие зависит от состава участников с той стороны, может быть, не на первой встрече, а на продолжении);

● ведущий консультант по системе (он будет показывать ERP-систему и делать по ней доклад);

● (опционально) ведущий разработчик (для оценок на лету возможности реализации того или иного требования в процессе разговора);

● если идет показ нескольких блоков системы, то консультанты и разработчики по блоками могут быть свои (в ERP-системах практикуется узкая специализация специалистов). Это еще плюс несколько участников.

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

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

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

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

Если совсем кратко, на что обратить внимание при проведении презентации:

● вежливость и внешний вид, впечатление профессионализма;

● интерес к проблематике заказчика, а не решению;

● показ возможностей системы в терминологии заказчика (их продуктовая линейка, отраслевая специфика);

● быть на одной стороне (в идеале – физически за столом тоже, иначе это сразу позиция противостояния);

● рассказать о процессе внедрения: не только показ системы и ее возможностей, а как именно все это будет происходить, что потребуется от сотрудников заказчика по этапам проекта;

● конспектировать вопросы и решения по ним;

● предоставить протокол встречи всем участникам в течение нескольких дней после презентации.

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

Об этапах проекта и его жизненном цикле речь пойдет в главе «Этапы и документация проекта».

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

Может сложиться ситуация, когда потребуется фиксировать суммы бюджета и сроки проекта уже на этом этапе и нужно давать финальное коммерческое предложение, без выделения предпроекта с обследованием и уточнением работ, сроков и бюджета в отдельный договор. Такая ситуация для оценки не очень приятная, придется «угадывать» трудозатраты, сроки и закладывать риски в оценку. Тут можно предложить заказчику провести блиц-опросы (по заранее подготовленным анкетам) и интервью ключевых сотрудников, хотя бы в течение нескольких дней. Это дополнительные затраты на работы со стороны исполнителя, но и минимизация рисков и более точные оценки будущего (возможного) проекта. Если же требований с должной детализацией у заказчика вообще нет, то и готовности к проекту нет, нужно настаивать на отдельных работах на предпроект, предлагать коммерческое предложение именно на него и дать «вилки» стоимости на основной проект с уточнением по результатам обследования. Конечно, всегда остается метод «угадывания» бюджета и сроков на все этапы проекта и по существующей информации, но это явные проектные риски для последующих этапов и значительные допуски в оценках.

2.3.Fit-gap анализ разных систем

Рассмотрим более детально вопросы анализа сближений (fit) и разрывов (gap) пригодности ERP-системы для компании согласно ее требованиям. Как провести такой анализ (исполнителю) по полученной спецификации функциональных требований и как потом эти результаты трактовать (заказчику)?

Если исполнителями являются не внешние специалисты, а команда сотрудников в штате компании, то подход тот же самый. Здесь и далее «исполнитель» – это специалисты, отвечающие за автоматизацию и хорошо знающие рассматриваемую ERP-систему, а «заказчик» – заинтересованная в проекте сторона, путь даже внутри одной и той же компании.

При fit-gap анализе за основу берется список требований от заказчика, он передается в составе RFP, разбит по разделам (модулям) системы: продажи, закупки, бухгалтерский и налоговый учет, производство, казначейство и прочие. Этот список переводится в таблицу, если изначально был не в виде таблицы, и к нему добавляются столбцы для оценок анализа.

Типовой шаблон таблицы для проведения fit-gap анализа содержит столбцы:

● Наименование требования – краткое описание критерия для оценки;

● Приоритет – важность и очередность для автоматизации: 1 – высший приоритет, 10 – низший;

● Обязательность – критичность реализации на первом этапе для запуска в эксплуатацию (так называемое must have – должно быть сразу);

● Поддержка – поддерживается штатно «из коробки»;

● Настройка – поддерживается настройкой системы (не требует программирования);

● Модификация – поддерживается доработкой (требует программирования);

● 3-я сторона – поддержка решениями третьих сторон;

● Будет в следующих версиях – поддержка анонсирована в следующих версиях решения;

● Не поддерживается – нельзя сделать, технические и функциональные ограничения;

● Комментарий к требованию – пояснения к требованию, ссылки на другие документы с детальным описанием;

● Комментарий к оценке fit-gap – пояснения выбранной отметки при анализе.

Варианты оформления таблицы для анализа разные, зависят от применяемой методологии (могут входить как готовые шаблоны в приложение к методологии). Шаблон может требоваться самим заказчиком, что логично: потом все сводить к единому виду.

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

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

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

Так или иначе, список критериев оценки может быть короче, если разделение не критично. В частных случаях это может быть два столбца в таблице: fit (поддерживается) и gap (не поддерживается). Собственно, потому и анализ fit-gap. Но нюансы существенны. Их тогда придется описывать в комментарии. Например, «не поддерживается» – да, но можно доработать. Или наоборот – «поддерживается» – да, но не из «коробки», а после модификаций или установки сторонних решений.

Потому выше рассмотрена более общая структура таблицы fit-gap анализа, где такие тонкости вынесены в отдельные столбцы.

Еще вариант этой таблицы: один столбец «fit-gap», в который ставится числовая оценка сближения или разрыва. Например, по шкале от 10 до 0, где 10 – подходит идеально, 1 – не подходит, 0 – нельзя доработать. Тогда промежуточные оценки показывают степень и сложность доработок.

Рис. 2.1. Пример таблицы fit-gap анализа требований

Как, собственно, заполнить этот файл на стороне исполнителя?

Привлекаются все эксперты (коллеги по компании-исполнителю) по системе:

● рассылкой по электронной почте для оценок каждым своего блока и первоначального знакомства с требованиями;

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

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

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

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

Заказчик, собирая такие fit-gap таблицы по своим требованиям, может их соотнести между собой, это позволит определить применимость той или иной ERP-системы, если идет выбор между разными системами. Поэтому столбцы для fit-gap анализа желательно добавить сразу на стороне заказчика, чтобы все участники тендера работали с одним шаблоном RFP и потом можно было соотносить результаты.

Если таблица объемная и зрительно сравнить затруднительно, вводится дополнительный столбец с оценками по каждой отметке, где проставляются баллы: поддержка «из коробки» – максимум, «не поддерживается» – ноль. Далее по сумме баллов определяется победитель.

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

Зато если система не подходит совсем, то это сразу будет видно по сплошным «разрывам» в анализе.

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