Стретегия бизнеса и роль IT проектов
Наш мир сейчас находится в состоянии четвертой промышленной революции, которая трансформирует цифровые технологии и объедединяет физический, биологический, химический и информационные миры. В связи с этим сильно возрастает роль IT в жизни абсолютно любого бизнеса, который для того чтобы выжить должен пройти путь цифровой трансформации, то есть переход на цифровые технологии, которые становятся основой для новых товаров и услуг, новых методов работы и новых бизнес-моделей.
Целью ведения любого бизнеса являетя получение прибыли.
Основным (но не единственным) источником прибыли и капитализации является операционный поток наличности — выручка, которую приносит компании ее непосредственная деятельность. Поскольку у любой компании существуют конечные потребители, количество которых ограничено, и она практически никогда не работает в сегменте рынка одна, у конкурентов необходимо забирать максимально возможный операционный поток наличности. Эта задача дости-
гается путем определения и реализации стратегии бизнеса. Иными словами, если цель бизнеса — экономические, социальные или иные стремления, ради которых существует предприятие, то стратегия бизнеса — это единый набор планов и действий, направленных на достижение основных целей бизнеса организации. Частью стратегии бизнеса является IT стратегия.
Разработка стратегии IT — важный и сложный процесс, который должен ответить на главный вопрос: как должна измениться архитектура ИТ в соответствии с архитектурой (моделью) бизнеса, которая, в свою очередь, корректируется с целью достижения новых требований бизнес- и функциональных стратегий.
Направления развития IT должны быть полностью интегрированы с направлениями развития бизнеса.
В связи с этим компании пробуют автоматизировать свои процессы с помощью ERP систем, разрабатывают сайты и мобильные приложения и создают внутри себя целые IT департаменты. Но не смотря на это многие инициативы заканчиваются негативно и компании остаются у разбитого корыта. Почему так происходит? Причин этому несколько и в этой статье я хочу поговорить о факторах успешности IT проектов и приведу пару примеров из своей практики участия во внедрениях, когда проекты заканчивались неуспешно и проанализирую причины таких провалов.
Существует множество статистик относительно успешности проектов и как показывает практика, какую из них не возьми статистика неутешительная, большинство проектов заканичваются неуспешно, а у тех проектов которые заканчиваются успешно статьи издережек на их завершение стремительно раздуваются, при этом в несколько раз. При этом если проект даже завершается и его цели вроде бы достигнуты, заказчик все равно может быть чем-то недоволен. И тут можно отметить первую причину неуспешности завершаемых проектов – заказчик сам не знает чего хочет, а если про что-то говорит, то не факт, что то что он говорит действительно ему нужно. Или же он может выпустит какую-то деталь, без которой он не сможет например работать, а потом когда проект уже подходит к концу он спрашивает: “а где же? я ж без этого не смогу работать. Это же само собой разумеется, что это должно быть”. В этом случае в провале проекта будет больше виновать сам заказчик, чем исполнитель.
В процессе ведения проекта задействуется несколько ролей: проектный менеджер, бизнес-аналитик и разработчик. При этом каждый из них отвечает за свой участок: проектный менеджер контролирует течение проекта, бизнес-аналитик определяет границы проекта, а разработчик отвечает за техническую реализацию.
Роль бизнес-аналитика в IT проекте и почему без него не обойтись
Как показывает практика заказчик не так плохо реагирует на рост объема проекта, как на рост его стоимости. Тут все понятно – он же за те деньги планирует получить больше, а вот для проекта это не очень хорошо, так как это снижает рентабельность проекта (если такой проект выполняется внешним исполнителем).
Для устранения такого риска все больше возрастает роль бизнес-аналитика, который является буфером между клиентом и командой разработки. При этом бизнес-аналитик должен хорошо разбираться в менеджменте, уметь анализировать бизнес-клиента, на основе этого анализа давать клиенту советы, думать категориями “Что нужно бизнесу” и “Зачем ему это нужно”, и только затем давать ответ на вопрос “Как это будет реализовано”. То есть он оперирует бизнес-требованиями. Вот тут для заказчика наступает коллапс головного мозга. Очень часто порой заказчики не понимают зачем им бизнес-требования, а хотят сразу описание функциональных требований.
Здесь сразу же нарушается целостность проекта и возникает риск того, что заказчик получит не то, что нарисовал в свое голове. Но это тема уже для другой статьи.
К сожалению для многих IT компаний роль бизнес-аналитика снивелирована и если он даже присутствует в проекте, то лишь для того, чтобы рисовать схемы процессов либо стенографировать поток мыслей клиентов, который затем передается разработчикам, которые начинаю “пилить” что-то, что может и не нужно клиенту. Поэтому очень большое распространение получают методологии, наподобие SCRUM, которые дают результат, но на которые нужно потратить больше времени и денег.
Но если посмотреть на определение, кто же такой бизнес-аналитик, в той же википедии, то:
Бизнес-аналитик — специалист, использующий методы бизнес-анализа для исследования потребностей деятельности организаций с целью определения проблем бизнеса и предложения их решения.
Международный Институт Бизнес-Анализа (IIBA, International Institute of Business Analysis) определяет бизнес-аналитика «как посредника между заинтересованными лицами для сбора, анализа, коммуницирования и проверки требований по изменению бизнес-процессов, регламентов и информационных систем. Бизнес-аналитик понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие организации достичь своих целей».
В консалтинговом бизнесе бизнес-аналитиком называется высшая позиция для консультанта.
Как мы видим, что бизнес-аналитик это все же больше про менеджмент, чем про IT.
Бизнес-аналитик профессия которая тоже в свою очередь имеет множество ответвлений (если нарпример говорить о разработке какого-нибудь продукта). Например можно выделить:
- Владельца продукта (Product Owner) – проектная роль, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой.
- Бизнес-аналитика, специалиста который мыслит категориями – “что” и “зачем” и который определяет бизнес-потребность клиента.
- Системного аналитика – специалиста, который анализирует потребности клиента на предмет возможности их удовлетворения посредством функций соответствующей информационной системы. Также его часто называют «постановщик задач». Основным продуктом такого системного аналитика являются организационно-технические решения, оформляемые как техническое задание (либо отдельные задачи) на систему или программное обеспечение.
- Бизнес-тренера – специалиста, который занимается обучением пользователей работе в системе.
- Архитектора бизнеса (бизнес-архитектор) – это человек, который инициирует создание новых бизнес-предприятий, ведет за собой архитектурные инновации бизнеса, проектирует передовые бизнес-модели и создает устойчивые сбалансированные бизнес-системы, ориентированные на долгосрочный успех. Но эта роль встречается очень редко.
В зависимости от размера проекта эти роли могут выполняться одним человеком либо выделяться отдельно.
Мне за свою практику довелось побывать на каждой роли либо их совмещать на разного уровня сложности проектов и каждая из них имеет свою ценность для проекта.
Основная задача бизнес-аналитика определить границы проекта, то есть его scope, то есть объем работ. Все мы помним знаменитый треугольник проекта
Хотя все про это знают, но получается вот так:
Объем проекта определяет его стоимость и количество времени нужное на реализацию этого объема работ. Особенно это важно для команд которые не работают по модели “Time and material”, которая подразумевает то, что по сути объем работ не важен, а команда тратит свое время, за которое платит заказчик. Если заказчик сказал, что-то не так, это его проблемы.
Команды работающие по модели “Фиксированная цена” заинтересованы в четкой фиксации того, что нужно реализовать. Тут основной проблемой становится то, что заказчик пытается схитрить и засовывать в этот объем работ, новые требования с упором на то, что он не сможет без этого работать. Таким образом команда попадает в ловушку из которой без потерь не вырваться. Ведь клиент не заплатит, ведь мы так много сделали, давайте эту штуку допилим. И так может продолжаться до бесконечности.
Бизнес-аналитик может снизить неопределенность в проекте и помочь определить реальный объем проекта. Хотя сделать это ой как непросто.
Теперь давайте поговорим о факторах успешности проекта.
Факторы успеха проекта
Для того чтобы ваш IT проект завершился успешно и чтобы сильно не выходил за рамки первоначально определенного треугольника проекта необходимо контролировать несколько факторов, которые сильно влияют на успешность проектов.
Фактор успеха 1. Поддержка руководства
Наверное это самый влиятельный фактор на успех проекта. Если руководители со стороны заказчика не поддерживают проект, то они на него будут неохотно выделять ресуры – свое время, деньги. Они будут его неохотно защищать, если в ходе проекта что-то пойдет не так. Сотрудники видя, что руководство неохотно поддерживает проект, тоже могут относится к нему прохладно и при случае даже вредить проекту.
Фактор успеха 2. Вовлечение пользователей
Этот фактор хотя и стоит на втором месте, но по своему значению такой же влиятельный. И тут я хочу рассказать историю из своей практики внедрения ERP системы, которая закончилась неуспешно.
Клиента заинтересовала ERP система, внедрениями которой занималась наша компания. Под этот проект была выделена команда бизнес-аналитиков, которые собрали требования и на основании этих требований была доработана система. Затем началось обучение сотрудников, которые по ходу обучения сгенерировали новые требования, которые также были реализованы. После первого обучения прошло несколько месяцев, сотрудники естественно все забыли и заказчик попросил провести обучения сотрудников по ролям: менеджер по закупке, менеджер по продаже, бухгалтер. Это обучение также было проведено, результатом этого обучения были персональные инструкции по работе в системе, которые сделали сами сотрудники. И вроде все было ок, но после завершения обучения ничего не произошло – сотрудники отказались работать в системе. Почему? ответа на этот вопрос нет до сих пор. Но по ходу этого проекта выявилась еще одна типичная проблема связанная с пользователями: они очень тяжело отказываются от систем где работали до сих пор. И не важно что это за система: это может быть обычная Excel либо 1с, либо вообще какая-то самописная система.
В связи с этим возникают требования, которые нельзя реализовать либо реализовать очень сложно.
Тут хочу привести пример уже из другого проекта. Заказчик заказал комплексную ERP-систему, которая охватывает практически все его процессы. До этого он работал в ряде устаревших систем, которые он захотел заменить одной. Первой преградой и причиной затягивагния сроков, стала плохая работа бизнес-аналитика, которые собирал требования по ряду основных сегментов (маркетинг, crmи продажи) в режиме стенограммы. Затем эти требования попали ко мне как к системному аналитику, которые были обработаны и на их основании программистам был поставлен ряд задач. После реализации система начала показываться клиенту, который начал говорит, что это не что мы ждали. В ответ мы начали говорить, что вот в требованиях написано так – вот так и сделано. И тут пришло откровение – заказчик начал говорить, что мы не ориентируемся на этот документ, он написан на непонятном для нас языке. После чего началось уточнение требований, что повлекло за собой дополнительные затраты с нашей стороны, которые естественно никто не компенсировал.
Но суть была не в этом) Одним блоком (Финансы) по этим требования занимался я, начиная от их сбора и заканчивая реализацией в системе и я четко знал, что все что было нужно – реализовано. И тут после демонстрации реализации требований возник новый как бы сказать “закидон” со стороны клиента: “Нам этим неудобно пользоваться. Вот смотрите как у нас это происходит сейчас в нашей программе” и открывает передо мной очень старую программу с допотопным интерфейсом, которая предназначена исключительно для учета денежных средств. “Вот смотрите как быстро я это делаю тут, а как долго буду делать там”. Хотя у нас полноценная учетная система, с полноценным учетом задолженностей, движением денежных средств и т.д. Еще одним открытием стало для меня то, что ни главный бухгалтер ни финансовый директор не оперировал счетами учета и проводками. Как они собирались делать такую форму отчетности как “Баланс” для меня загадка.
Если говорить вообще про внедрения, то про пользователей вспоминают в самом конце. Требования как правило собираются с тех людей, которые в результате не будут пользоваться этим функционалом. Например требования по функционалу, которым будут пользоваться бухгалтера собираются с финансового директора. На это есть несколько причин и они вполне очевидны и с ними я могу согласится.
Во-первых, пользователи как правило не очень разбираются в IT. И порой от них могут исходить требования, которые сложнореализуемы либо нереализуемы вообще (например – самостоятельное создание новых объектов). При этом эти требования еще могут меняться по ходу проекта. Сегодня хочу вот так, а завтра уже по другому. А как оно влияет на смежные сегменты системы мало кого волнует.
Во-вторых, требования от пользователей могут расти постоянно, даже когда уже процесс внедряется. И чем сложнее внедряемая система, тем сложнее внести в нее изменения.
Если же пользователей не привлекать, то они потом будут жаловаться на то, что их мнения не справшивали и они не будут этим пользоваться.
С точки зрения пользователей, сотрудники IT департамента или компании часто приходят к ним, задают два-три вопроса и уходят куда-то на пару месяцев, а потом приносят какое-то решение, которое их как пользователей не устраивает, даже если там действительно реализованы все необходимые функции.
Устранить эту проблему сложно, но возможно. Сейчас указывать на все пути не буду – это станет темой отдельной публикации, а сейчас могу дать такую рекомендацию: вовлекайте пользователей пораньше, но с помощью хорошо продуманного управляемого процесса. Отыщите эксперта в определенной области и работайте с ним. Определите конкретные результаты их участия и “высекайте требования в камне”, тогда удастся избежать раздувания масштабов.
Поэтому здесь особую роль играют правильно сформулированные требования к системе, а это процесс непростой, труднозатратный, но стоящий, как говоря “овчинка стоит выделки”.
И постарайтесь определить критерии приемки со стороны пользователей.
Фактор 3: опытный руководитель проекта
На успешность проекта также оказывает сильное влияние руководитель проекта.
Руководитель проекта (менеджер проекта, project manager, PM) – это специалист, отвечающий за успешное выполнение проекта: в указанные заказчиком сроки, с необходимым качеством, при фиксированном бюджете, ограниченных человеческих ресурсах и в соответствии с требованиями со стороны заказчика. Зачастую это административный руководитель функциональной проектной группы, который обеспечивает оперативное руководство и контролирует осуществление работ, проводимых в рамках проекта. В условиях постоянного усиления конкуренции особенно актуальными становятся готовность компании к непредвиденным поворотам событий и способность грамотных менеджеров предугадывать, планировать и управлять изменениями. В бизнесе работа по проекту является своего рода искусством и требует умений, времени и сил. Чтобы проект стал успешен, руководитель проектов обеспечивает:
- видение проекта как объекта управления, понимание его особенностей;
- анализ, учет интересов и управление отношениями со стейкхолдерами проекта;
- снижение неопределенности уникальной задачи за счет процедуры планирования;
- ресурсную базу проектных мероприятий;
- защиту проектных решений и отчетность перед куратором и заказчиком;
- привлечение проектных групп и отдельных исполнителей к выполнению работ;
- контроль за ходом выполнения работ;
- анализ проектных событий на предмет своевременности, качества, отклонений;
- составление прогнозов и коррекцию планов;
- завершение проекта и архивирование документации.
Если эту позицию занимает человек некомпетентный, то у проекта резко снижается шанс успешно его завершить. Этот специалист должен отслеживать состояние клиента, говорить о рисках проекта и контролировать состояние проекта. Если проектов под его руководством больше чем один, то нужно еще правильно проводить ресурсное планирование, ведь ресурсы которым он управляет небезграничны.
Также конечно же желательно контролировать бюджет проекта и его рентабельность. Зачем вам проекты, которые работают в минус?
Фактор успеха 4. Четко определенные цели проекта
Это первый фактор который не связан с человеческим фактором. И хотя все про этот фактор знают, но большинство проектов которые запускаются не имеют четко определенных целей.
Это очень похоже на отношение всех к утренней гимнастике – все признают, что делать ее надо, но никто не делает.
Отговорок тоже целая куча. То лень, то какие-то организационные факторы, то жесткие сроки, а то и реструктуризация компания.
Но, подумайте, если вы например не знаете зачем вам например ERP-система и какие задачи она должна решать, получите ли вы в итоге, то что вам нужно. Наибольший интерес в определении целей проекта имеет заказчик проекта. И если он надеется, что команда исполнителей сама что-то придумает и сделает и он получит то что нужно. Ну ну……
Фактор успеха 5. Четко определенный (и уменьшенный) объем работ
Вполне очевидно, что чем больше срок выполнения проекта, тем меньше вероятность того, что он будет завершен успешно. Цели проекта определяют его объем. Отсюда вывод – если нет целей, то объем проекта можно сказать безграничен.
Одной из проблем при внедрении есть то, что заказчик раздувает объем работ до максимума в ту сумму, которую он собирается заплатить. Если исполнитель идет на поводу и соглашается, то заказчик войдя во вкус фантазирует все больше и больше. Как результат – команда исполнителя работает в минус и соответственно теряет мотивацию успешно завершить проект, клиент не удовлетворен и все бьются в истерике (это я пошутил, наверное).
Тут менеджер проекта должен понимать, что за определенное количество времени можно выполнить определенный объем работ. Если принимается решения задействовать дополнительные ресурсы (то есть людей), то необходимо помнить, что чем больше человек принимает участие в решении проблемы, тем дольше она будет решаться.
Все мы знакомы с таким мемом:
В жизни приблизительно так и происходит.
Обычно единственным путем уменшить время работы над проектом – ограничить его объем. Во многих случаях имеет смысл разбить проект на маленькие и краткосрочные проекты.
Фактор успеха 6. Более краткосрочное планирование, большое число контрольных точек.
Как вы поняли смертельным врагом успешности проекта является время. Поэтому вас не должен удивить этот фактор. Большие проекты как правило деляться на вехи.
Вехи проекты – своеобразные маркеры, которые помогают двигаться по плану проекта и указывающие важные на важные этапы или события. Это могут быть фазы проекта, переходные точки в которых должны быть собраны внешние данные, ресурсы или решения или просто контрольные точки. Чем чаще вы намечаете контрольные точки, тем успешнее будет ваш проект, тем ранее вы заметите, что проект пошел не туда и тем больше у вас будет времени на корректировку курса проекта. Но не переусердствуйте, слишком много таких точек будет демотивировать вашу команду.
Фактор успеха 7. Четко определенный процесс управления проектом.
Итак, “больше времени, больше денег и больше людей” – это не залог успеха проекта. Главными факторами успеха будет вовлечение в работу нужных людей и четкое определение ключевых элементов проекта.
Опытный менеджер проекта уже владеет технологией успешного ведения проекта, если же нет, то по всей вероятности ваш менеджер проекта не контролирует проект, а если этого не делает он, то как правило не делает никто. Если вы слышите от менеджера проекта – я не контролирую проект, то можете такой проект уже похоронить.
Процесс управления проектом должен быть максимально простым и четко определенным. Если процесс меняется каждый день, то это будет вводить сумбур и непонятность. Здесь может помочь разработка и внедрения регламентов, но это не так просто как кажется. Наличие регламента не гарантирует его исполнение.
И помните, что процесс ради самого процесса – это бесполезная трата времени. Хорошо определенный процесс управления проектом не избавит от всех проблем, но может снизить уровень ошибок и повторной работы наполовину, что может сэкономить значительную часть стоимость проекта.
Ограничения проекта
Давайте вернемся к треугольнику проекта и выведем такую формулу:
Масштаб = время*стоимость*качество
Масштаб – это общий объем работ в рамках проекта. Однако такой объем определяется еще и тем, чего не надо делать в проекте.
Время – общее время, которое займет работа над проектом. Чем больше вы хотите сделать, тем больше времени вам на это понадобится.
Стоимость – цена проекта, включающая прямые и непрямые издержки.
Качество – про него мы еще не говорили и многие это ограничение упускают или про него просто не думают. Обычно это первое, что приносят в жертву, когда проект выходит за рамки поставленных сроков или бюджета. Оно также снижается, когда вознкают ошибки, упущения или исправления из-за плохого планирования.
Менеджер проекта должен провести такое планирование, которое даст представление о всех этих 4-х элементах. Потом они могут стать целями проекта.
Выводы
Современный бизнес постоянно находится в поиске конкурентных преимуществ, которые дадут ему возможность выжить на рынке и развиваться. Одним из факторов успешности бизнеса является применение им IT технологий и если оно увенчалось успехом, то у него уже есть преимущество перед конкурентами. Именно поэтому бизнес находится в поиске решений, которые структурируют его работу либо дадут ему “фишку” которой нет у конкурентов.
Большинство проектов, которые инициируются бизнесом, заканчивается неудачей, причин этому великое множество. Анализ этих причин привел к факторам которые необходимо контролировать и вовремя сигнализировать о негативных тенденциях.
Если вы начинаете какой-нибудь проект, например внедрения у себя ERP-системы, помните о том, что успех такого проекта по большей мере зависит в основном от вас, а не от подрядчика которого вы наймете для его выполнения.
