Comments 17
Ничего нового для тех, кто имеет непосредственное отношение к автоматизации бизнес-процессов. Но продолжайте, иногда выговорится полезно.
Добрый день!
Да, не открыл Америку. Но, вероятно, Вы в теме, как непосредственный участник процесса. Но почему продолжаем ходить по граблям? Сколько в Вашей практике, с Вашей точки зрения, было неуспешных проектов?
Что есть не успешный проект? Например, потратили 10 млн, чтобы бизнес остался на плаву, а могли тоже самое получить за 2 млн - это не успешный проект? Или, качественно внедрили документооборот, а бизнес загнулся от кривых бизнес-процессов в отделе продаж?
Предлагаю для определения успешности проекта оперировать целевой функцией и степенью её достижения. Если, как Вы пишете, документооборот внедрен качественно, цель достигнута - проект успешен. Он же имел граничные условия. Ведь не стояла задача, например, повысить доходность бизнеса? Которая потребовала бы, вероятно, пересмотра многих бизнес процессов.
Что касается стоимости реализации проекта, то это, скорее, вопрос морально-этический.
Это у исполнителя "целевая функция", а у бизнеса задача минимум выжить при изменении условий, а максимум - увеличить прибыль.
Мы говорили о конкретной ситуации - успешности реализации проекта. Однако, если у бизнеса проблемы в продажах, а ресурсы решено вложить в документооборот, это и есть отклонение от целевой функции - как минимум выжить. Только не проекта по документообороту, а бизнеса. Конечно, не знаю подробности о предложенном Вами примере, но естественный отбор никто не отменял. Остается только вспомнить профессора Преображенского: "разруха - она в головах".
Но почему продолжаем ходить по граблям?
Потому что исполнители набирают опыт и учатся, а заказчик ж каждый раз новый, опыта у него 0. И не каждый поверит в "вот мы знаем, что так, как вы хотите, не работает". И либо не работать с такими, т.е. с большинством рынка, либо продолжать ходить по граблям.
Да, естественно, у исполнителя (как правило) опыт реализации значительно шире. Мало того, исполнитель работал и с аналогичными организациями и с многими другими. Но, думаю, что Ваш вопрос скорее в плоскости продаж. Если заказчик сомневается в вашей экспертности, будут проблемы. Либо уже в процессе выполнения проекта всплывают пробелы в Ваших компетенциях - недоверие будет налицо, а реабилитироваться очень сложно.
Если заказчик сомневается в вашей экспертности
Вы тут всё в кучу смешали. Заказчик обычно - руководитель какой-то, один конкретный человек, который не сомневается - он вас нанял, сомневался бы - не нанял. Другое дело все остальные сотрудники компании, у каждого свои тараканы в голове могут быть. Но какое это отношение имеет к тому, что я писал выше? Я не про продажи говорил, а про итоги внедрения.
Вы правы, в первую очередь для заказчиков
Практически все проекты по автоматизации в ходе разработки и внедрения отклоняются от первоначального ТЗ. Причин очень много. Например, первоначальное исследование и описание бизнес-процессов было выполнено не очень качественно. Самая большая боль проектов, когда меняется ключевой заказчик. В моей практике, таких проектов половина. И этот риск очень сложно, практический не возможно минимизировать.
Риск замены ключевого заказчика всегда есть. Как правило приводит к пересмотру технического задания и, соответственно, договора (корректировка сроков, стоимости). Предусмотреть возможно на уровне Устава проекта в части корректировки задач, сроков.
По поводу не качественного описания БП, да, бывает. Причем, как правило, дилемма не разрешима. Заказчик: а вы нас про это не спросили, Исполнитель: да вы про этот процесс не рассказали....
Наталия, Вы же закладываете эти риски в стоимость/сроки выполнения работ по проекту?
Да, ничего нового, мир не идеален, клиент не знает чего хочет, разработчик не умеет читать мысли и прочее. А вы с какой целью и для кого хотите этот пул примеров расписать? Научить заказчиков как общаться с разработчиками?
Как не впустую потратить ресурсы и не пожалеть о внедрении программного обеспечения