среда, 10 апреля 2019 г.

Ошибки обоснования внедрения комплексной системы (ERP, MES, PLM)


Дополненный рерайт статьи https://www.cimx.com/blog/you-can-build-a-business-case-for-an-mes

Пытались когда-нибудь уговорить трехлетнего малыша доесть тарелку овощей?
В большинстве случаев вы ищете тактику, которая сработает. Начинаете обычно с логики: "Это полезно для твоего организма!" Потом пробуете угрозы: "Съешь свой горошек, пожалуйста!". Переходите к бартеру: "Я дам тебе десерт, если ты доешь горошек". Если ничего из этого не сработало, то пробуем другие стратегии, например, реверсивную психологию: "Я понял, ты не стала бы есть такие хорошие горошинки". Либо самоидентификацию: "Марине нравится горошек, она его ест". Под конец мы спускаемся в бездны безумия: "Картошечке, которую ты уже съела, так одиноко в твоем животике, может она поиграть с горошком, пустишь его к себе?" Переговоры продолжаются до тех пор, пока вы не найдете подходящую тактику. И во многих случаях вы ее не находите.
К сожалению, многие попытки внедренцев убедить лиц, принимающих решения, напоминают такие вот уговоры трехлетнего ребенка съесть горошек. Команда внедрения понимает, что есть проблема, и даже скорее всего, много проблем. Они должны представить убедительный набор доказательств для начала проекта, но не знает, с чего начать. И они начинают пробовать все методы убеждения подряд, плодить своими действиями беспорядок, который только больше запутывает ЛПР. Потому что ЛПР не трехлетний ребенок, он помнит предыдущие аргументы. Но кроме того ЛПР принимает кучу решений, поэтому крайне важны не только сами расчеты, но и форма подачи. Например, в Cisco внедряли Wi-Fi в офисе, когда эта технология только-только появилась и стоила космических денег - по 500 долларов на работника в год. Руководитель не мог принять решение, потому что сумма была существенной. И тогда менеджер проекта посчитал - если Wi-Fi экономит сотруднику хотя бы 1 минуту в день, то проект финансово оправдан. Решение было принято незамедлительно.

Как правильно строить обоснование, которое позволит убедить начальника стартовать проект?
1. Сосредоточьтесь на одном эффекте внедрения
2. Планируйте внедрение по этапам
3. Посчитайте сумму потерь из-за продолжения текущих порочных практик

Сосредоточьтесь на одном эффекте внедрения
Множество проектов внедрения начинаются с решения одной проблемы текущего процесса. Как  правило, это связано с бумажным документооборотом и неформализованными коммуникациями. Это может быть несоответствие качеству, длительные инженерные изменения, ошибки в ВОМ, некачественные данные и неточная/несвоевременная отчетность, отсутствие производственного контроля.
К сожалению, после того, как подходящее решение этой проблемы найдено, команда начинает добавлять функциональность в проект. Персонал, бюджет и сроки в таком разбухающем проекте растут куда быстрее, чем возможные выгоды. На каждые 10 месяцев проекта успешность проекта падает примерно вдвое. Начальная проблема теряется в ворохе новых сложностей.
Поэтому, когда строите обоснование, не добавляйте функциональность. Она резко увеличит затраты, но скорее всего никак не повлияет на эффекты внедрения. Сосредоточьтесь на решении начальной проблемы. Если возврат начальных инвестиций будет положительным, то вам будет легче обосновать дальнейшие вложения.

Планируйте внедрение по этапам
Гораздо проще обеспечить поддержку проекту, который делает ряд небольших изменений, чем для монолита, который рушит всю старую систему. Такое поэтапное внедрение позволяет быстро получить эффекты от внедрения.
Возможная последовательность такого внедрения:
1. Установить метрики, поставить цели
2. Определить команду и ответственного за улучшения (не более 4 человек)
3. Собрать данные и описать процесс "как сейчас"
4. Создать принципиальное описание улучшенного процесса "как будет"
5. Написать инструкции по каждому шагу
6. "Продать" изменения стейкхолдерам
7. Пробный запуск улучшенного процесса
8. Одобрить развертывание
9. Провести пилотный запуск и обучение
10. Постоянно улучшать процесс
11. Закрепить улучшения, удалить все следы старых процессов
Источник: Engineering Documentation Control Handbook, 2nd Ed.: Configuration Management for Industry Frank B. Watts

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

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

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

Комментариев нет:

Отправить комментарий