|
|||||||||
|
|||||||||
Литература: Автор: Adame Deane Оригинал статьи:http://adamdeane.wordpress.com/2012/06/27/anti-case-studies-bpm/ Я люблю читать о разных кейсах. Они всегда позитивны. Пришли, увидели, победили. Заказчику понравилось решение. Заказчик получил огромный ROI. Проект был выполнен в сжатые строки, в рамках бюджета. Заказчик согласился выдать за вас свою дочь, и все жили долго и счастливо. Кейс 1: обход ИТНачиналось все замечательно. Заказчик увидел решение, был впечатлен и хотел побыстрее оформить сделку. Бизнес команда – мощный департамент, со своим собственным бюджетом. Все что было нужно – это получить «галочку» в поле ИТ-отдела. Я знал, что у заказчика есть скрытая проблема. Только не знал, какая… Мне удалось выяснить, что у них уже было одно BPMS-решение от другого вендора, но им оно показалось слишком сложным неуклюжим, и что использовать его могут только ИТ-специалисты. Потребовалась целая вечность, чтобы заставить ИТ сделать хоть что-то на существующей платформе. Они же хотели создать очень простой процесс согласования самостоятельно. … они искали способ обойти ИТ. Был бюджет, были люди. Первая презентация для бизнес-команды и для менеджмента прошла отлично. «Вау!» и «Ох!» от всех участников. Вторая презентация для ИТ-отдела началась хорошо. Они задавали общие технические вопросы, и были довольны ответами. Внезапно ИТ-менеджер начал задавать раздражающие вопросы. Затем его прорвало: Почему его не предупредили о встрече заранее? Почему его обошли? Какого черта мы ищем другое BPM-решение? Он требовал ответов. «У нас уже есть 7 различных BPM решений от семи вендоров. Да… некоторые их них не используются, а некоторые используются не должным образом… но это не повод покупать решение другого вендора.» В этот момент разразилась внутренняя дискуссия между бизнесом и ИТ. Они кричали друг на друга, обвиняли друг друга, вопили, орали… Вызвали полицию… (ок. я слегка преувеличиваю) Вынесенный урок:
Кейс 2: создание приложенийЭто было похоже на простой проект. Фиксирование рабочего времени. Там не было реальной необходимости в процессе, но нравилась веб-платформа. Спустя несколько месяцев (и спустя два менеджеров проекта…) мы увидели его в действии. С превышением сроков, с превышением бюджета. На потерянные деньги можно было купить небольшой домик. Вынесенный урок:
Кейс 3: Обеспечение реальной прибылиОн создавал впечатление важного проекта. Одним из европейских правительств был принят закон, заставляющих избранных министров сделать более прозрачным процесс принятия решений. Изображение процесса было грандиозным. Две сотни шагов в длину. Чтобы запустить его от начала до конца, потребуется несколько лет. Впечатляет! Тем не менее, в процессе было только два участника – министр и его помощник. Я посмеялся немного позже. Оказалось, что министр не умеет пользоваться компьютером, поэтому в основном процесс был написан для помощника министра, который посылал задания самому себе. Я уверен, что они используют его. И я уверен, что это принесло им «большую» пользу. Приятно знать, что наши налоги идут на благие цели… Вынесенный урок:
Урок:Говорят, мудрые люди учатся на чужих ошибках. Дураки – на своих. Комментарии |
|||||||||
Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | |||||||||
|
Если бы он жил в России, он первым кейсом сделал бы кейс № 1 "обход ИТ" по другому ))) Примерно так: Заказчик не увидел предлагаемого решения, поскольку прежде чем его посмотреть потребовалось провести аудит проекта через его ИТ подразделение, а там возмутились тем, что им предложено решение на котором отсутствует возможность получить комиссию от вендора или интегратора и проект был отклонен как бесперспективный.
Вынесенный урок:
Ищите Заказчиков, у которых здравый смысл и требования бизнеса превалируют перед предпочтениями ИТ специалистов (или ЛПР их заменяющих)к применяемому ПО.
Избегайте общения с ЛПР в организации Заказчика, которые, оценив предлагаемый проект, сразу поймут свою невостребованность в процессах организации по факту реализации проекта и начнут препятствовать его реализации.
Анализ внутренней политической ситуации это Ваша работа.
"Никогда не создавайте НЕ-BPM решения на платформе BPMS"
Несколько настораживающее утверждение.
Есть документ, информация из которого одновременно идет в систему учета, а некоторые данные запускают процесс.
Выходит нельзя вносить его в одну форму, требуется дублировать информацию. Иначе все закончится провалом?