Какими критериями стоит руководствоваться при выборе партнера на проект по автоматизации? Часть 2.

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

4. Теперь перейдем к непосредственному знакомству с компаниями и их методикой работы.

Общение можно вести в офисе партнера, где вы сможете оценить действительный размер компании, ее отношение к сотрудникам, но тогда вам надо будет планировать выезд. Можно пригласить партнера к себе. Также прекрасный способ первого знакомства – удаленные переговоры (Skype, web конференции и пр..).

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

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

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

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


• Объем участия специалистов предприятия в проекте. Здесь мы в первую очередь говорим о кураторе проекта и ответственных за отдельные функциональные блоки (т.е. ответственных со стороны бизнеса). Данный вопрос является продолжением предыдущего. Получив ответ, вы сможете проверить свои оценки занятости ваших сотрудников, участвующих в проекте, и внести необходимые корректировки. Если, например, партнер говорит вам, что плановая занятость куратора проекта со стороны Заказчика будет не более 10%, то это означает, что партнер собирается как можно меньше согласовывать с вами ход проекта. Казалось бы, как удобно, но не приведет ли это к ситуации: "А разве мы это хотели получить в результате проекта"? И даже если цели проекта будут достигнуты, вариант реализации может вас не устроить.



По нашей оценке занятость куратора проекта со стороны Заказчика, если одновременно внедряются 3 учетных блока, составляет 60-70%. Поэтому когда представители предприятия говорят, что хотят одновременно запустить все учетные блоки системы, то сразу возникает вопрос, а готовы ли они выделить отдельную группу сотрудников, у которых не будет текущей работы и которые будут заниматься только проектом? И будут ли они работать по 8-12 часов на протяжении всего проекта, не выгорят ли? Обсуждая данный вопрос, вы может прийти в итоге к уточнению сроков проекта, количества одновременно внедряемых блоков, составу своей команды на проекте.

• Участие сотрудников ИТ-службы клиента в проекте. Если есть собственная ИТ-служба, то вам должно быть интересно, как она будет задействована в проекте. Ответы подрядчиков могут быть очень полярны: от "мы все сделаем сами" и до того, что партнер может предложить произвести запуск системы силами собственной ИТ-службы, а себе оставит только создание модели будущей системы. И то и другое будет отрицательно сказываться на реализации проекта. Если ИТ служба не будет участвовать в ходе проекта, то после его завершения будет не способна поддерживать систему, помогать пользователям (т.е. остается только вариант пост-проектного сопровождения партнером). Да и вариант с запуском системы ИТ-службой предприятия тоже плох. Созданная модель показывает общие принципы работы и может не учитывать отдельные особенности (особенно встречающиеся не часто). Отсутствие опыта не позволит самостоятельно искать ошибки пользователей, вносить корректировки в разработанные схемы. Вероятнее всего такой запуск будет провальным.

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

Здесь мы уже частично затронули и следующий вопрос.

Чуть подробнее остановимся на 2-х вопросах. Как будет осуществляться передача системы сотрудникам предприятия? Какие варианты сопровождения бывают после окончания проекта?

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

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

Т.е. у вас должен быть выбор.

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

Вроде бы оптимальный ответ подрядчика: "мы сделаем все, как вы захотите". К сожалению, данный ответ является и самым неподходящим при выполнении проекта. Причин на это много:

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

b. У предприятий, как правило, есть планы развивать систему и после окончания проекта. И новая функциональность может попросту вступить в конфликт с сильно переписанным внедренным функционалом. Новые функции могут просто не заработать. Придется заново пересматривать сделанные настройки, дорабатывать их. А это время и деньги.

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

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

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

• Можно с партнером обсудить, какие риски проекта он видит на основании своего опыта.

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

По ответам можно будут судить о том, насколько большим опытом обладает партнер.

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

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

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

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

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

6. Ну что ж, партнер выбран, команда выбрана и можно приступать к внедрению? Можно, но перед стартом желательно сделать последнее – проверить партнера в работе. Ведь комплексный проект длиться не менее 1-2-х лет.

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

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

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

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

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

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

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

Удачных вам проектов.