5 основных причин, из-за которых проваливаются проекты

Причины провала ИТ-проектов

Примерно 10 лет назад от одного из успешных бизнесменов, в компании которого я руководил проектом внедрения КСУП (о том, что это – подробнее читайте здесь), я услышал такую фразу: «Бизнес сидит на игле у ИТ».

Меня заинтересовало ее объяснение, и оно было примерно таким: «Мы не можем не автоматизировать наш бизнес, потому как конкуренты это сделают ранее нас и станут эффективнее нас, и, с другой стороны, мы боимся это делать, т.к.

вероятность успеха ИТ-проекта крайне низка».

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

Обратите внимание

Отчет, который в 2014 году выпустила компания The Standish Group, предоставляет нам следующие данные для анализа:

Из 8 380 проектов по разработке и внедрению программных продуктов успеха добились лишь 16,2%, в категорию «спорные» проекты попало 52,7%, а в категории провальных проектов (от реализации которых отказались) оказалось 31,1%.

Для целей исследования в этом отчете все ИТ-проекты были разделены на три группы:

• «успешные проекты» — проект завершен в срок, в бюджет, реализованы все возможности и функции, которые первоначально были запланированы;
• «спорные проекты» — проект завершен и работает, но плановый бюджет или срок был превышен, либо реализованы не все функции, которые первоначально были запланированы;
• «провальные проекты» — проект был отменен и так и не дошел до финиша.

Как часто превышается бюджет ИТ-проекта и на сколько % от планового значения? На этот вопрос отчет дает нам следующий ответ:

Превышение бюджета % проектов Менее 20% 15,5% 21 — 50% 31,5% 51 — 100% 29,6% 101 — 200% 10,2% 201 — 400% 8,8% Свыше 400% 4,4%

Как видим, почти в четверти проектов, из тех, что попали в группу спорных или провальных проектов, бюджет был превышен более чем в 2 раза (свыше 100% от планового).

А теперь посмотрим, как сильно отклоняются от планового срока ИТ-проекты:

Превышение срока % проектов До 20% 13,9% 21 — 50% 18,3% 51 — 100% 20,0% 101 — 200% 35,5% 201 — 400% 11,2% Свыше 400% 1,1%

А вот по срокам ситуация куда более серьезная – почти в половине проектов (47,8%), попавших в группу спорных или в группу провальных, сроки были сорваны более чем на 100% от плановых.

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

% реализованных функций % проектов Менее чем 25% 4,6% 25 — 49% 27,2% 50 — 74% 21,8% 75 — 99% 39,1% 100% 7,3%

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

Не знаю, как Вам, а мне интересно было узнать мнение руководителей ИТ-проектов относительно причин успеха их проектов. Ниже перечислены факторы успеха и доля респондентов, указавших их:

1. Вовлечение пользователей — 15,9%
2. Поддержка высшего руководства — 13,9%
3. Ясное изложение требований — 13,0%
4. Правильное планирование — 9,6%
5. Реалистичные ожидания — 8,2%
6. Небольшие этапы проекта — 7,7%
7. Компетентный персонал — 7,2%
8. Ownership — 5,3%
9. Ясное видение и цели — 2,9%
10. Трудолюбивый, сфокусированный персонал — 2,4%
11. Другое — 13,9%

В аналогичном отчете The Standish Group за 2015 год в списке появились новые факторы успеха ИТ-проекта, которых не было в списке за 2014 год, например:

• Эмоциональная зрелость — совокупность основных характеристик поведения людей при совместной работе. 
• Использование Agile процесса – обозначает то, что команда и владелец продукта умеют работать по одному из Agile подходов.

Как видим, в 2015 году респонденты в явном виде указали на то, что использование Agile-подхода для ИТ-проекта стало одним из факторов его успеха.

Самое интересно при изучении статистики проектов, на мой взгляд, — это понимание причин того, почему проект не стал успешным. По мнению респондентов отчета список этих причин для спорных проектов следующий:

1. Отсутствие вовлечения пользователей — 12,8%
2. Неполные требования и спецификации — 12,3%
3. Изменение требований — 11,8%
4. Отсутствие поддержки высшего руководства — 7,5%
5. Технологическая некомпетентность — 7,0%
6. Нехватка ресурсов — 6,4%
7. Нереальные ожидания — 5,9%
8. Нечеткие цели — 5,3%
9. Нереальные плановые сроки — 4,3%
10. Появление новой технологии — 3,7%
11. Другое — 23,0%

Понятное дело, что в исследовании The Standish Group не участвовали ИТ-проекты компаний-заказчиков из Беларуси.

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

Ниже представлена моя точка зрения на список причин провала проектов автоматизации бизнеса, без претензии на его истинность:

1. Нечеткие цели ИТ-проектов.

Это проявляется на уровне самих формулировок целей проекта, к примеру, целью ИТ-проекта объявляют такую: «Внедрить ERP-систему».  У меня много вопросов к этой формулировке цели:

• Что мы понимаем под ERP?
• Как мы поймем, что мы внедрили эту систему?
• Какова бизнес-выгода от внедрения?
• За какой период будем измерять бизнес-выгоду?

Следующий уровень, который скорее всего будет не проработан при старте проекта – это описание ожидаемых результатов проекта. Ну и совсем слабой в большинстве проектов будет проработка требований к результатам проекта. (подробнее читайте здесь)

1. Отсутствие со стороны компании-заказчика проекта команды проекта

Я имею ввиду команду, которая имеет полномочия и ответственность принимать решения по содержанию проекта.

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

1. Неполные требования к программному продукту.

Большинство заказчиков ИТ-проектов из числа белорусских компаний не готовы платить за полноценный сбор и анализ требований те деньги, которых это действительно стоит.

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

Это приводит к следующей причине провала проекта.

1. Нереальные плановые сроки

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

Проявляется этот фактор в том, что на стороне заказчика хотят сразу сделать идеальный продукт и не принимают позицию, связанную с тем, что пользователям все равно что-то не понравится в программном продукте, поэтому важно максимально быстро запустить ключевой функционал, а потом потихоньку дорабатывать «бантики». По статистике, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда (подробнее тут).

1. Отсутствие поддержки высшего руководства компании-заказчика

Я встречал ситуации, когда при внедрении ERP-систем высшие руководители компании-заказчика даже не были представлены команде исполнителя. О каком вовлечении в проект или поддержке проекта руководством со стороны заказчика может идти речь?

1. Команда заказчика и команда исполнителя не работают как одна команда.

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

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

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

Подводя итоги, что нужно изменить в ИТ-проекте, чтобы максимально повысить вероятность его успеха? Понятно, что нужно решить те проблемы, которые описаны в списке выше.

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

Получится создать такую команду – и она с большой вероятностью решит все остальные проблемы.

Тут я вспоминаю один из пунктов манифеста Agile:

«Люди и взаимодействие важнее процессов и инструментов», который я трактую так: «Хорошая команда проекта определит, какие процессы и инструменты ей надо использовать, чтобы достигнуть целей проекта». Agile – это про хорошие команды. Может поэтому в списке причин успеха ИТ-проектов в отчете компании The Standish Group за 2015 год появилась новая причина успеха — использование Agile процесса?

Остались вопросы? Пишите в комментариях к статье.

Источник: http://project-management.zis.by/statistika/prichiny-provala-itproektov.html

5 главных причин провала стартапа — обсуждение на Quora — Трибуна на vc.ru

Пользователь Quora попросил участников сервиса вопросов и ответов написать пять ключевых причин, из-за которых проваливаются стартапы. Редакция ЦП выбрала самые интересные комментарии из обсуждения.

Чаще всего в обсуждении фигурирует причина «недостаток финансирования». Одни пользователи упоминают её в качестве одного из главных факторов, губящих проекты, другие напротив считают, что её переоценивают.

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

Важно

Участник обсуждения Джеймс Фердинад Ликанта (James Ferdinand Lukanta) в свой список включает склоки между сооснователями, несвоевременный запуск, недостаток внимания к пользователям и рынку.

Глава венчурного фонда из Сан-Франциско Society3 и S3-Accelerator Алекс Шульц, работавший более чем с 100 стартапами и запустивший пять собственных проектов за последние пять лет, приводит следующие причины провалов:

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

Инвестор и венчурный капиталист с тридцатилетним стажем Пол Кон (Paul Cohn) в качестве ответа публикует таблицу базы данных CBInsights с 20 самыми популярными причинами провалов стартапов.

Первые три позиции в ней занимают «отсутствие заинтересованности рынка», «недостаток финансирования», «неподходящая команда».

Но во втором пункте Кон солидарен с Шульцем — он также считает, что «недостаток финансирования» скорее является последствием иных причин, чем самостоятельным фактором.

Пользователь Quora Кен Якобсен (Ken Jacobsen) считает иначе и дважды пишет в своем рейтинге «деньги», а также указывает на некомпетентность персонала, проблемы, связанные с масштабирование проекта, и недостатки продукта. Консультант по управлению и писатель Питер МакКэнн (Peter McCann) в списке из двух пунктов первым также ставит недостаток денежных средств, а вторым — «бредовый менджмент».

Основатель компании-организатора марафонов по живописным местам Америки Vacation Races Сэлям Стэнли (Salem Stanley) приводит свой рейтинг:

Пятую причину Стэнли придумать не смог, так как все провалы, которые ему довелось видеть, вполне укладываются в четыре упомянутых им.

Совет

Бухгалтер Крис Баскервиль (Chris Baskerville), оформивший более 700 банкроств, публикует детальный рейтинг:

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

• Почему вы решили запустить свой проект?
• Кому он может помочь?
• Не сделал ли этого кто-либо до вас?
• Каким образом вы сможете обойти конкурентов?
• За счет чего вы намерены получить «преимущество первого хода»?

Читайте также:  Amazon: принципы антикризисного реагирования от джеффа безоса

Источник: https://vc.ru/tribuna/6602-fail-reasons

Причины провала проектов

Серия «Секреты управления»

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

Когда вы пытаетесь разобраться, почему застрял или провалился какой-либо проект, то обнаруживаете на поверхности множество объективных причин. Но это только видимые причины. За остановкой или провалом проекта всегда стоит кое-что еще. И это кое-что — чьё-то противодействие.

Считать причиной неудачи чью-то нерадивость является ошибкой. Проекты проваливаются не из-за чьей-то лени или ошибок.

Если вы прилагаете хоть какие-то усилие для того, чтобы дело двигалось, – любое усилие – то оно начнет двигаться, если только нет скрытого сопротивления.

Так устроен этот мир: если никто не прилагает усилий, направленных против ваших усилий, то ваши усилия заставят двигаться то, к чему вы их прилагаете. Это физика.

Кто-то прилагает сосредоточенные усилия, чтобы остановить ваши начинания. Хотите измерить усилия, которые прилагаются, чтобы вас остановить? Измерьте собственные усилия. Чтобы остановить то, что вы толкаете, противоположные усилия должны быть равными вашим, или превышать их.

Давайте рассмотрим это на примере. На одном из проектов мы пытались ввести еженедельную статистику «Потери сырья». На протяжении двух недель никак не удавалось запустить сбор данных.

Обратите внимание

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

И если вначале они были достаточно логичными, то по мере того как я их разбивал, аргументы становились все более глупыми.

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

Новые владельцы не последовали закону джунглей, и на входе не сменили топ-менеджмент. А эти господа, быстро сообразив, что владельцы не имеют опыта в данной сфере, подняли процент естественной убыли сырья с 0,25% до 3%.

После того как уволили причастных к махинациям сотрудников все наладилось.

За годы работы консультантом и занятий бизнесом я избавился от иллюзий. Что-то никак не получается? Что ж, я ищу а не рассуждаю о возможных причинах, ищу тех, кто останавливает.

Проект по запуску ERP-системы идет со скрипом, несмотря на давление со стороны владельца и нашу помощь? Давайте посмотрим, кто нам мешает.

Проводим расследование,— и вот они голубчики: финансовый директор и главный бухгалтер, которым работающая учетная система как кость в горле. Убираем,— и все пошло как по маслу.

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

Важно

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

Так как наша работа увязывала воедино результаты двух других групп, я координировал совместные действия. В какой-то момент общую работу начала стопорить команда, которая занималась бухгалтерией. И Причины для этого были вполне объективные. Сначала никак не удавалось наладить работу центральной кассы. Что, мягко говоря, удивительно.

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

Потом были проблемы с наймом бухгалтеров, что опять-таки делается обычно в пол щелчка. Вернее их нанимали, но они увольнялись, не проработав и трех дней. Самое смешное, что и для увольнения у них были объективные причины.

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

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

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

Когда дошло до постановки управленческого учета, он испугался, что двое других совладельцев обо всем узнают. Ситуацию мы уладили: настояли на том, чтобы он пообщался с партнерами, и они пришли к согласию, после чего проект стронулся с места.

Совет

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

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

После чего предупредить, что если подобное повторится (не ошибка, а пытка ее скрыть мешающая работе компании), он будет уволен, и отпустить с Богом. И всегда выполняйте свое обещание: проколется еще раз — увольте. Но не поступайте так, как некоторые наши клиенты. Не давайте шанс сотруднику, пойманному на крупных хищениях.

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

А через полгода, проводя аудит системы, мы снова поймали ее на «жареном». Нельзя любить людей больше, чем они любят себя сами.

Для того, чтобы кто-нибудь не наломал дров, коротко упомяну еще об одной причине противодействия сотрудников. Они с вами не согласны. Когда человек не согласен, он сопротивляется. Посмотрите, как ведет себя ребенок, который не хочет утром идти в детский сад. Он просто «олицетворение сотрудничества». Он ведет себя так, потому что вы навязываете ему то, что он не хочет.

Так же и сотрудники. Чаще всего их несогласие вызвано:
1) Непониманием. Они не понимают, для чего что-то делается.

Если человек не деградировал окончательно (а вам такие не нужны) то когда он чего-то не понимает, он не говорит: «Я туп». Он решит, что задуманное вами неразумно.

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

Обратите внимание

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

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

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

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

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

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

Будет неплохо также предупредить их, что если еще один проект с их участием провалится, то они будут уволены.

Успехов вам в ваших проектах.

Источник: https://Professionali.ru/Soobschestva/upravlenie_proektami/prichiny-provala-proektov/

CRM Простой бизнес

Смотреть мастер-класс по теме

https://youtube.com/watch?v=4yo3iycOS3I

Успех любой организации связан с успешной реализацией проекта! Можете ли вы назвать какие-либо значительные инициативы или улучшения, осуществляемые организацией, которые не связаны, по крайней мере, с одним проектом? Лиза Андерсон, президент Консалтинговой группы LMA Inc, консультант по менеджменту и управлению поставками, работала со многими организациями в самых разнообразных отраслях во всем мире. По ее мнению, организаций, не использующих в своей работе процесс управления проектами, не существует. Но если успех проектов автоматически приводит к успеху организации, то провал проекта приведет к ее краху. Анализируя свои проекты и деловые контакты, Лиза Андерсон выделяет три наиболее распространенных камня преткновения на пути к успешной реализации проекта.

Отсутствие четко обозначенного руководителя проекта

Просто удивительно, сколько раз возникает этот, казалось бы, простой вопрос. Существует много причин, когда в качестве проектной команды выступает группа сверстников, но никто из них не назначен руководителем или не принимает руководство.

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

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

Важно

Однако нет ничего более важного для успеха проекта, чем его руководитель. На это есть множество причин.

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

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

Несомненно, Ваш проект будет сорван без явного руководителя проекта!

Отсутствие четких ожиданий и целей

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

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

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

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

В результате прогресс в выполнении поставленной цели, в значительной степени зашел в тупик, пока цели и показатели проекта не были уточнены.

Проблемы коммуникации

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

И это продолжается до тех пор, пока сообщение не обойдет всех человек, участвующих в игре, по кругу.

К тому времени сообщение, полученное последним участником игры, никогда не похоже на исходное! В конечном итоге, бывает очень интересно услышать перепутанные сообщения ваших друзей, образовавшиеся после 10-20 изменений.

Совет

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

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

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

Читайте также:  4 примера, как малый бизнес сокращает затраты с помощью it

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

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

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

Система автоматизации бизнес-процессов «Простой бизнес» является инструментом руководителя проекта для управления профессиональной деятельностью персонала.

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

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

Смотреть мастер-класс по теме

Архив новостей по управлению

Источник: https://www.prostoy.ru/557.html

20 основных причин провала стартапов

Иногда кажется, что все самое захватывающее достается именно startup-компаниям.

Они создают новые рынки, подрывают устои старых, получают фантастические суммы от венчурных капиталистов, устраивают сумасшедшие вечеринки по случаю запуска, имеют самые клевые офисы и так далее.

Но так ли легко на самом деле достичь звездной стартап-жизни или за идиллическими стереотипами скрывается суровая реальность?

Правда заключается в том, что 90% таких компаний обречена на неудачу.

Звучит ужасно? Пока вы привыкаете к этой мысли, отметим также, что венчурные деньги достаются лишь 1% первопроходцев, 82% финансируют себя сами, а 24% предпринимателей полагаются на поддержку друзей или семьи.

Обратите внимание

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

Являетесь ли вы просто интересующимся наблюдателем, предпринимателем или обеспокоенным инвестором, скорее всего, вам любопытно узнать, как происходят такие «неприятности». Итак, какова главная причина провала 90% стартапов?

5 причин почему мечты о стартапе могут остаться только мечтами

Масштабирование бизнес-процессов на ранних этапах

Если верить экспертам из Startup Genome, главная причина провала бывает во многом связана с феноменом «преждевременного масштабирования» (Premature Scaling).

Нейтан Фюр, преподаватель основ предпринимательства в Университете Бригама Янга и автор книги с метким названием «Преуспей — затем масштабируй» (Nathan Furr, Nail It Then Scale It), определяет это явление как «траты денег на вещи, не являющиеся неотъемлемой частью роста бизнеса (такие как наем штата менеджеров по продажам, дорогой маркетинг, доведение продукта до идеала, аренда офисов и т.д.), до того, как удалось успешно найти продуктовую/рыночную нишу».

На примере двух стартапов можно изучить, как выглядит преждевременное масштабирование на практике:    

Красной линией обозначена компания Color, масштабированная раньше времени. Зеленой линией отмечена Rally, степень ее развития была оценена верно

Стадия развития компании определяется характером взаимодействия и реакцией клиентов.

Преждевременное масштабирование имеет место тогда, когда действия компании не соответствуют стадии, на которой находится бизнес.

В основном это происходит в результате десинхронизации пяти основных показателей: клиент (Customer), продукт (Product), команда (Team), финансовые показатели (Financials) и бизнес-модель (Business Model).

Важно

В верхней части схемы (слева направо) приводится модель реальных стадий проекта по Мармеру (Actual Marmer Stage), она описывает прогресс стартапа на основе его взаимодействия с клиентами: 

1. Открытие (Discovery)
2. Оценка и подтверждение ценности (Validation)
3. Эффективность, отдача (Efficiency)
4. Масштабирование (Scale)
5. Поддержание (Sustain)
6. Сохранение (Conservation)

Компания Color, для которой свойственна переоценка масштаба, находится на второй стадии, а Rally, чья ступень развития была определена адекватно, — на третьей. 

Далее сверху вниз разворачиваются «поведенческие» стадии проекта по Мармеру (Behavioral Marmer Stage), касающиеся линии поведения стартапа относительно пяти ключевых показателей, отмеченных выше. 

• Как видно из рисунка, Rally ориентируется на понимание потребностей своего клиента, в то время как Color устраивает большую PR-кампанию, обычно планируемую на стадии поддержания. 
• Продукт Color не отличается завершенностью, а UX является неэффективным. Rally же проводит ребрендинг продукта по результатам оценки соответствия инвесторским требованиям.
• Что касается команды, опять-таки Rally опирается на проверку инвестором показателей прошлого месяца прежде чем начать набирать новых ее участников. В Color сразу же набрали большой штат (30+ человек).
• В Rally сделали большой раунд венчурного финансирования (Series A Round) только после проверки соответствия требованиям инвестора в прошлом месяце, а Color получил огромные капиталовложения ($41 000 000) в самом начале. 
• Color не имеет четкой бизнес модели. Приложение Rally работает безукоризненно.

Таким образом, движение Rally по схеме происходит линейно, демонстрируя эффективность, а действия Color отличаются непоследовательностью (преждевременным масштабированием).

Масштабирование бизнеса: 3 урока от Uber

Почему они канули в лету?

Фюр отмечает еще одну распространенную причину неудач: стартапы предпринимают умные шаги, но делают это в случайном порядке.

Другими словами, они занимаются тем, что, в общем-то, имеет смысл, например, инвестируют в разработку продукта, нанимают отличных специалистов, помогающих продать его, работают над маркетинговыми материалами и т.д.

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

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

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

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

Хотите узнать остальные причины гибели стартапов? Вот 20 наиболее распространенных от CB Insights — платформы, занимающейся анализом данных по венчурным капиталам, стартапам и патентам: 

Топ-20 причин провала стартапов (на основе анализа 101 компании). Отсутствие потребности рынка в данном продукте/услуге — 42%. Закончились деньги — 29%. Неудачная команда — 23%. Были вытеснены конкурентами — 19%. Проблемы с ценой/стоимостью продукта — 18%.

Плохой продукт — 17%. Недостаточная продуманность/отсутствие бизнес-модели — 17%. Неэффективный маркетинг — 14%. Игнорирование нужд клиентов — 14%. Несвоевременность продукта — 13%. Потеря ориентира — 13%. Отсутствие согласия в команде/среди инвесторов — 13%.

Резкое изменение бизнес-модели (pivot) не пошло на пользу — 10%. Недостаток энтузиазма — 9%. Неудачный выбор локации — 9%. Отсутствие финансирования/интереса инвесторов — 8%. Юридические трудности — 8%. Неиспользование связей/советов консультантов — 8%. Выдохлись — 8%.

Не смогли изменить бизнес-модель — 7%

Почему 75% новых продуктов обречены на провал?

Критический разбор причин провала

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

Было бы неплохо, если бы существовал сайт с историями различных проектов, позволяющий учиться на ошибках и в идеале избегать их на своем пути. И такой ресурс существует. Если хотите получить свою порцию наглядных уроков, загляните на Autopsy.io.

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

Совет

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

Специально для читателей блога LPgenerator мы перевели приведенный на скриншоте отрывок таблицы:

Autopsy.io — уроки провалившихся стартапов

Дата проведения аутопсии Стартап Идея Причина провала Июнь 2015 Fastr  Whatsapp для службы клиентской поддержки «Неправильный подход, неверно выбранный целевой рынок»  Июнь 2015 GuGo Коллективная платформа социальных навыков «Несогласие сооснователей, не смогли предоставить финансовые гарантии»  Май 2015  Allmyapps Первый магазин приложений для пользователей ПК с системой Windows для облегчения поиска, установки и обновления ПО «Уделили недостаточно времени выработке видения на ранних этапах, слишком рано начали тратить на маркетинг, поспешили с наймом штата и многое другое»  Май 2015 BitShuva Radio Pandora для нишевых музыкальных жанров и групп, исполняющих музыку в стиле инди «Провалившаяся бизнес-модель строилась вокруг кастомизированных версий ПО, а следовало сделать отдельную платформу»  Апрель 2015 KOLOS Первый руль для автогоночных видеоигр, совместимый с iPad  «Люди не проявили интереса»  Апрель 2015 Bluebird Squarespace c ПО с открытыми исходными кодами и шаблонами «Отсутствие финансового и операционного контроля наряду с неопытной управленческой командой» Апрель 2015 Secret Анонимное рассказывание личных секретов «Перестало соответствовать видению, которое у меня было вначале»  Март 2015 Kiniku Считывание электрических сигналов тела и с помощью этого управление вещами  «Обдурили инвесторы, у которых одновременно было несколько проектов»  Февраль 2015 ComboCats Платформа для многопользовательских игр на основе очередности «Последствия российско-украинского конфликта»  Февраль 2015 College Inside View Предоставление более детальных студенческих обзоров колледжей «Не получилось собрать достаточное количество обзоров»  Январь 2015 Cusoy Инструмент поиска ресторанов для людей с аллергиями на определенные продукты на основе отзывов  «Не было ясного, предсказуемого метода самодостаточного развития»  Январь 2015 Starthead Чешский краудфандинговый сервис для пользователей во всем мире «Мы были наивными идиотами»  Январь 2015 Poliana Визуализация политического влияния «Не начинайте компанию, чья деятельность связана с политикой, если только не собираетесь быть некоммерческой организацией»  Декабрь 2014 Zagreb Cohousing Пространство для совместного проживания в г.Загреб, Хорватия «Неправильный выбор места и целевой аудитории»  Ноябрь 2014 Springpad Цифровые записные книжки «Не смогли подняться до уровня самоокупаемого бизнеса»  Октябрь 2014 Keep Fit Stay Sane Эмоциональный тренажерный зал онлайн «Не смогли найти рыночную аудиторию»  Октябрь 2014 Amiloom Устройство, создающее сеть людей с общими друзьями «Нельзя объяснить за 3 секунды»  Сентябрь 2014 Emjoyment Аналог Tinder для вакансий и предложений «99 причин сразу и ни одна из них одновременно»  Август 2014 Dinnr Доставка ингредиентов для обеда в день заказа «Просто не хватило людей» 

Как оценить соответствие вашего продукта ожиданиям целевого рынка?

Заключение

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

https://youtube.com/watch?v=fiUG18vRcwM

Высоких вам конверсий! 

Источник: https://lpgenerator.ru/blog/2016/11/18/20-osnovnyh-prichin-provala-startapov/

10 причин провала проектов по описанию бизнес-процессов

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

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

  Итак, перед вами ТОП-10 причин неудач внедрения исходя из нашего личного опыта:

1. Невнятные цели и нечёткие сроки

Деятельность по описанию бизнес-процессов необходимо рассматривать как проект. А у проекта должен быть руководитель, этапы, чёткие сроки и конкретные измеримые задачи (цели). Само по себе «описание процессов» – не может являться конечной целью проекта.

Читайте также:  Нужно ли проводить заработную плату сотрудников через ккт?

Несколько хороших примеров постановки целей проекта:

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

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

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

Первично оценить выполнение таких целей достаточно просто (речь пока что не идёт об эффективности): вы либо сформировали набор документов, либо нет; требования к вакансиям либо определены, либо нет.

Примеры плохих целей:

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

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

2. Отсутствие вовлеченности руководства

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

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

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

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

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

3. Перекладывание ответственности на консультантов

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

Они рассуждают так: «Почему бы не поручить данную задачу консультантам или привлечённому со стороны бизнес-аналитику? Ведь они построили уже множество процессов и наверняка справятся с этой работой лучше нас».
К сожалению, это большая ошибка. Даже самые опытные консультанты, построившие сотни процессов не могут знать все нюансы деятельности вашего предприятия.

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

Обратите внимание

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

Они могут помочь с обучением сотрудников, формированием планов и постановкой целей. На начальных этапах они помогут выделить основные бизнес-процессы и, за счёт своего опыта, избежать типичных ошибок и подводных камней.

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

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

4. Недостаточный уровень зрелости предприятия

Вот вам реальный пример из нашей практики. Руководитель одного производственного предприятия обратился к нам за помощью. Проблемы стандартные: сотрудники работают неэффективно, перекладывают ответственность друг на друга, заказы срываются, клиенты не довольны.

Было решено выполнить проект по описанию бизнес-процессов с целью регламентации ответственности и внедрения простой системы контроля.
Но в результате этой деятельности большинство сотрудников решило уволиться.

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

Оперативно найти им замену не удалось, так как предложение руководителя на рынке труда было неконкурентоспособно, ведь на соседнем заводе платят в 2,5 раза больше.

5. Построение модели под конкретных людей (родственников/друзей и т.п.)

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

1. Перевести сотрудника на другую должность, которая соответствует его навыкам и личным качествам;
2. Оправить сотрудника на дополнительное обучение;
3. Уволить сотрудника;

А что делать, если этот неэффективный сотрудник чей-то друг/сват/брат? В лучшем случае – такому сотруднику найдут такую работу, где он не будет мешать остальным. А в худшем – поставят руководить подразделением или создадут под него целую отдельную бизнес-структуру.

Кейс из нашей практики: описывая бизнес-процессы небольшого предприятия мы обнаружили, что должность «заместитель главного маркетолога» практически ничего не делает. Всю основную работу выполняют либо подчинённые, либо руководитель подразделения.

Наше предложение сократить данную должность, либо распределить ответственность за текущие работы более равномерно было проигнорировано, так как данную должность занимала двоюродная сестра директора из другого города.

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

6. Нежелание руководства делегировать ответственность

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

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

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

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

7. Саботаж со стороны наёмных сотрудников

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

Данная проблема возникает как следствие из уже описанных в предыдущих пунктах проблем: недостаточной вовлеченности руководства и перекладывания ответственности за проект по описанию бизнес-процессов на внештатных специалистов. Обмануть привлечённого консультанта намного проще, ведь он не знает специфику работы предприятия.

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

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

8. Перфекционизм и стремление к совершенству

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

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

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

Важно

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

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

9. Ложные надежды и ожидания

Давайте будем откровенны, описание бизнес-процессов – это не панацея от всех бед.

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

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

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

10. Нежелание обучаться/читать руководство пользователя и методики

Конечно читать руководство пользователя скучно, а проходить обучение – не интересно. Но знаете, что ещё менее интересно? Построить множество бизнес-процессов и лишь после этого понять, что выбранный программный продукт не поддерживает подобное расположение блоков и для полноценной работы необходимо описать бизнес-процессы заново.

Или вот вам ещё один пример из нашей практики: пользователь распределял ответственность за функции бизнес-процессов не на должности, а на физических лиц и понял это только после попытки сформировать должностную инструкцию.

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

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

Если вы до этого строили бизнес-процессы в CRM-системе или системе документооборота, то этот опыт хоть и будет полезен, но не всегда применим к системам бизнес-моделирования, ведь у них разные цели и задачи.

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

Источник: https://blog.iteam.ru/10-prichin-provala-proektov-po-opisaniyu-biznes-protsessov/