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

27.08.20

Управление проектом

В предыдущей статье https://infostart.ru/1c/articles/1268138/ мы поговорили про критерии выбора партнера, единый формат оценки и отбор наиболее интересных подрядчиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

УДАЧНЫХ ВАМ ПРОЕКТОВ.

ТОИР 1С:ТОИР Управление ремонтами и обслуживанием оборудования

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3009    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

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

26.04.2024    4127    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3452    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3334    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15085    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6183    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5245    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

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

12.01.2023    5807    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1166203 27.08.20 12:06 Сейчас в теме
Добрый день.
Поделитесь, пожалуйста, дополнительно своим опытом по видам используемых контрактов. Насколько часто заказчики соглашаются на T&M и каков процент успешности таких проектов?
2. Steelvan 305 27.08.20 13:36 Сейчас в теме
Если я правильно понял, с вражеского T&M это почасовка ?

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

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

Если наемник работает один, то имеет смысл брать заказы от N рублей.
Иначе мелочевка много времени займет.
Оставьте свое сообщение