«Правильные» подходы к внедрению программных продуктов

Как было сказано ранее, опросника в качестве основы для крупного проекта по внедрению будет не достаточно.  Нужно готовить более подробное и детализированное описание проекта внедрения. Примеров множество в сети интернет. И чем сложнее проект, тем более важным является описание автоматизируемых бизнес процессов с различных точек зрения (руководитель, подчиненный), времени (сейчас, через год) и вида (как есть, as is, икак должно быть, to be).

Вообще существует множество подходов к организации ПРОЕКТА внедрения программного продукта.  Именно ПРОЕКТА. Существует множество методологий работы с проектами: Водопад, PMBoK, Agile и еще множество страшных слов… Но сводятся все они в конечном счете к циклу Деминга — Шухарта — PDCA.

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

Причин для этого может быть несколько. Основные:

  • Отсутствие на предприятии группы специалистов, ответственной за внедрение. На предприятии должна быть КРИТИЧЕСКАЯ масса высокопоставленных специалистов, понимающих куда нужно двигаться и каким образом достигать намеченных целей. И важно, чтобы эти цели формулировало высшее руководство.
  • Низкая вовлеченность будущих пользователей программного продукта в процесс внедрения, непонимание целей внедрения, собственных задач, недостаточная мотивация на обучение, низкий уровень знаний и отсутствие контроля руководства над деятельностью.
  • Попытка подстроить программный продукт под существующие методы работы (лоскутную автоматизацию) вместо проработки и оптимизации существующих бизнес процессов в единый механизм (попытка «натянуть сову на глобус»). Неадекватное использование чужих наработок для своего бизнеса. Последним очень грешат франчайзи, предлагая решения, вполне удачные для одного предприятия и совершенно неприспособленные для другого.
  • Боязнь получения результата. Возможны ситуации, когда высшее руководство или заместители декларируют некие цели, например повышение прозрачности использования денежных средств, а на самом деле решения этой задачи по разным причинам пытаются не допустить. В качестве примера могу привести опыт работы зама директора по ИТ на одном из предприятий приборосторения около 14 лет назад. Ставилась задача создать единую систему от технического задания на входе до программ на станки ЧПУ на выходе. Короче связка CAD-CAM-CAE-PLM-ERP2. Было своими силами произведено обследование предприятия, оцифрованы бизнес процессы, схематизированы (IDEF), составлен альбом документов, используемых на предприятии с образцами заполнения. Был найден подрядчик и (бесплатно!) проработан контрольный пример на 5 изделиях. Причем во всех случаях общения с исполнителями достаточно было использовать результаты обследования. При обследовании было выявлено множество никому не нужных функций, ошибок учета и прочих досадных мелочей. Через некоторое время контрольный пример был продемонстрирован высшему руководству и среднему управленческому звену. Если среднее звено было готово включаться в работу фактически сразу, то с высшим руководством вышла заминка. Генеральный сказал, что если договор согласовывают замы, то все это запускаем в работу, финансовый директор поинтересовалась, можно ли это приобрести дешевле… Но технический директор в приватной беседе сказал, что до меня работали и после меня будут работать также как и сейчас и все эти новшества никому нафик не нужны. Коммерческий сказал, что в данный момент для системы нет объективных данных. И на этом все заглохло. Команда внедрения была деморализована и мы расползлись кто куда… А жаль. Как выяснилось позже у всех руководителей были свои «бубновые» интересы.
  • Недостаточно верное определение проблемных зон и соответственно неверное определение способов воздействия. Встречал организацию, где проблемы были в производстве и проблемы технического характера, а напрягалась руководством бухгалтерия, чтобы опосредованно выявить причины нестабильной работы производства. Как в анекдоте: «…А где ты потерял часы — Там — А чего же ищешь здесь — А здесь светлее».
  • Программный продукт куплен «потому что все покупают и устанавливают» или по настоятельной рекомендации знакомого франчайзи.
  • Имеются попытки сэкономить на специалистах или оборудовании. Понятно, что специалист стоимостью условно 120 тыс.рублей, сможет какое то время проработать условно на 60 тыс. рублей, но недолго, месяц — два. И все. И два специалиста по 60 тыс. рублей чаще всего не могут заменить одного за 120. И оборудование, уникальное для 2010 годов отказывается нормально работать в 2021 году. Даже если оно полностью исправно.

Вот это основные случаи, когда проект внедрения обречен. Спасти проект в данном случае может только «упертость» руководителя проекта, граничащая с фанатизмом.

Но адепты Agile Scrum скажут, что благодаря системному подходу, все вышеуказанные проблемы будут периодически всплывать и команда их решит. Но, для этого должна иметься КОМАНДА КВАЛИФИЦИРОВАННЫХ СПЕЦИАЛИСТОВ и в методике SCRUM и в предметных областях. Вопрос только в том, где их взять и сколько они стоят. Если они «внешние», то они будут пытаться в первую очередь решить СВОИ проблемы, а не проблемы предприятия, если они внутренние — то вопрос где их взять, как содержать и мотивировать. Про KPI поговорим в следующий раз, поскольку мотивация посредством может …хи-хи… работать во вред предприятию. Следует также заметить, что наличие сертификатов у специалиста, ответственного за внедрение, не означает успешности внедрения, это говорит о том, что он знает и умеет применять инструментарий продукта, а сумеет ли он переломить сопротивление пользователей — другой вопрос.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *