Внедрение информационных систем для предприятий «под ключ»: взаимопонимание Заказчика и Поставщика

Под термином «внедрение информационной системы (ИС) под ключ» подразумевается поставка и внедрение ERP-системы в полном соответствии с ожиданиями и требованиями клиента.

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

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

СОДЕРЖАНИЕ

1. Чем внедрение комплексной информационной системы (КИС) отличается от обычных услуг?

   a. Пример продукта и сопутствующих услуг

   b. Об информационных системах (ИС), программном обеспечении (ПО) и информационных технологиях (ИТ)

   c. Пример КИС и сопутствующих услуг

2. Заказывать или не заказывать техническое задание (ТЗ)?

3. Как выбрать программное обеспечение (ПО)

4. Варианты внедрения

5. Что требуется от заказчика КИС

6. Что требуется от поставщика КИС

7. Сколько потребуется времени

8. Тестирование

9. Когда можно подписывать акт выполненных работ

10. Что осталось за кадром

Чем внедрение комплексной информационной системы (КИС) отличается от обычных услуг?

Пример продукта и сопутствующих услуг

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

Все просто и понятно всем. Есть продукт, и есть сопутствующие услуги.

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

Сам производственный цикл достаточно сложен: много этапов, разные группы изделий проходят по различным производственным циклам, изделия необходимо отслеживать индивидуально. Основной процесс производства (тканья) также очень сложен и практически невозможен без применения станков с числовым программным управлением (ЧПУ).

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

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

Теперь об ИС, ПО и ИТ

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

Чтобы в общем понять проблему нематериальных активов (НМА), обратимся к музыке. Это очень древний нематериальный (духовный) актив. Казалось бы, за тысячелетия существования музыки (по аналогии с коврами) ее суть должна быть однозначно понятна всем. Но попробуйте найти двух человек, которые абсолютно одинаково объяснили бы на словах, что для них значит музыка, или какую музыку они хотели бы слушать.

В чем аналогия? И музыка, и ПО преимущественно существуют в сознании людей. А все люди разные, и соответственно понимание сути каждого НМА у них будет хоть чем-то, но отличаться.

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

Еще одно принципиальное отличие – отсутствие каких бы то ни было стандартов для процессов производства ПО, сплошные НЕОБЯЗАТЕЛЬНЫЕ РЕКОМЕНДАЦИИ и методики. Например, методика разработки в небольших группах программистов «Экстремальное программирование», которое значительно упрощает все процессы, сводя до минимума документацию, тестирование, предусматривая взаимодействие заказчика и поставщика в полуигровой форме. Из практики известны случаи, когда один человек, сидя дома, создавал ПО.

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

Но самое главное отличие нематериальных активов от материальных заключается в следующем: один ковер уходит к одному потребителю, и для второго потребителя нужно производить второй ковер; в случае НМА это не так, и одно и то же однажды произведенное ПО может попасть к большому количеству потребителей.

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

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

Пример КИС и сопутствующих услуг

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

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

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

Заказывать или не заказывать ТЗ?

ТЗ нужно тогда, когда необходимое программное обеспечение невозможно найти в готовом виде. Объем ТЗ напрямую зависит от объема планируемых изменений. Если количество доработок существенно превосходит объемы уже готового функционала, тогда лучше купить только основу (платформу), а конкретное решение (конфигурацию) разрабатывать «с нуля» на базе ТЗ. Иногда в качестве ТЗ может выступать документация по уже существующей системе, по каким-то причинам не удовлетворяющей заказчика. В случае с коврами ТЗ необходимо только когда речь идет об индивидуальном заказе. Ясно, что необходимо письменно оформить заказ, указав все параметры ковра и приложив рисунок. Это и есть так называемая постановка задачи (ПЗ) – краткое изложение требований клиента.

Итак, ПЗ нужна всегда. ПЗ начинается с целей проекта, определяет состав программного обеспечения и приоритеты внедрения.

ТЗ необходимо, если не существует готового или аналогичного программного обеспечения.

ПЗ выступает своего рода гарантией, что приобретаемый продукт решит сформулированные задачи.

ПЗ должен сформулировать заказчик, так как только он знает, что хочет получить в результате.

Как выбрать ПО

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

А для сложного проекта найти хороших консультантов не так просто.

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

Варианты внедрения

Внедрение ковра имеет не так много вариантов — повесить на стену или положить на пол.

Внедрение заказного ПО (например, ERP-системы) – сложнейший процесс, состоящий из демо-версий, презентаций, инсталляций, тестирования, доработки, повторного тестирования и эксплуатации.

Причем Заказчик ОБЯЗАТЕЛЬНО затратит на него много собственного времени, иначе без этого проект ждет провал.

Что требуется от заказчика КИС

Внятно формулировать требования

Понимать необходимость постоянного участия на каждом этапе

Обладать базовыми знаниями ИТ и компьютерной грамотности

Владеть компьютером на уровне уверенного пользователя

Выделить время каждому этапу проекта

Приказами назначить сотрудников, ответственных за сроки

Назначить грамотного менеджера (координатора) проекта со своей стороны

Выделить денежные ресурсы

Иметь и использовать опыт аналогичных проектов

Подготовить рабочее место для исполнителя

Что требуется от поставщика КИС

Иметь и использовать опыт аналогичных проектов

Владеть адекватными задаче информационными технологиями

Обладать достаточным количеством грамотных специалистов

Назначить грамотного менеджера (координатора) проекта со своей стороны

Взять на себя обязательства по поддержке программного продукта

Сколько потребуется времени

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

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

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

Тестирование

Этот процесс в принципе существует и для ковров: покупаешь ковер – и пробуешь по нему ходить. Не понравилось – несешь обратно к продавцу: он или деньги вернет, или на другой ковер заменит.

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

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

Когда можно подписывать акт выполненных работ

Актов должно быть несколько – в соответствии с наиболее важными этапами проекта:

1) Акт о развертывании системы (в режиме демо-версии) на территории заказчика. Фиксирует готовность инфраструктуры заказчика и установку ИС с демонстрационной (готовой «как есть») конфигурацией от поставщика (которую, возможно, показывали при демонстрации системы), предоставление стандартной документации и обучающих видеокурсов.

2) Акт о завершении сбора требований к системе (ПЗ). Фиксирует момент сбора 50-80% всех входящих и исходящих данных в ИС, а также завершение ознакомления с существующим функционалом ИС представителей заказчика на основе демоверсии.

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

4) Акт о вводе в промышленную эксплуатацию. Фиксирует завершение совместного тестирования и переход заказчика к работе в новой системе.

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

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

Что осталось за кадром

Смета и стоимость проекта

Проблемы управления проектами

Особенности каждого проекта и люди, которые в них участвуют

И помните: дорогу осилит идущий!