Работа с требованиями при автоматизации процессов планирования. Как не получить «лоскутное одеяло» и при этом удержать границы проекта

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

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

При этом я не программист и не ИТ-аналитик, я не работаю с конфигуратором. Я глубоко изучаю возможности таких решений, как ERP, УТ, УНФ с точки зрения их функциональности для решения бизнес-задач – смотрю логику настройки процессов в системе, объекты и возможности их применения.

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

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

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

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

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

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

Сфера деятельности предприятия – производство и продажа биологических добавок, парафармация: травяные сборы, мази и т.д.

Контур автоматизации – планирование продаж.

Цель – повышение эффективности планирования продаж, увеличение продаж и все, что вокруг этого выстраивается.

Основные инструменты системы, которые были задействованы:

• планирование продаж по менеджерам – нужно было как-то наладить и автоматизировать этот процесс, чтобы управлять продажами;

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

• данные и статистика по предконтрактной работе с клиентами – то, что реализуется в 1С через механизм «Сделки».

Результат автоматизации – чуда не случилось:

• Дело в том, что у бизнеса, связанного с БАДами, есть определенная сезонность – летом люди меньше болеют, и соответственно меньше покупают лекарства и все, что продается вокруг лекарств (витамины и биологически-активные добавки). Активный спрос начинается осенью и ближе к зиме. Летом у этой продукции спад.

• Отдел продаж, как обычно, запланировал на лето объем реализации по статистике продаж прошлых периодов.

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

• А производство, зная, что у них не сезон, отпустило персонал в отпуск, чтобы народ в этот период не простаивал.

• В итоге: спрос вырос, товар со склада выбран, а производство не может его восполнить. Как следствие у нас проблема – неудовлетворенный спрос клиентов и конфликт между продажами и производством.

Почему так происходит? Давайте разберемся в цикле планирования.

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

• планирования продаж;

• планирования закупок для производства и финансовых потоков под их обеспечение;

• планирование ремонтов производственного оборудования и так далее.

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

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

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

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

• Если у нас классическая производственно-торговая компания, которая планирует от спроса, потребностей рынка – у нас в основе вытягивающая система, где план продаж стимулирует план производства, план производства стимулирует закупки и т.д.

• Но в случае, если у нас промышленное производство – например, машиностроительный завод, или производство поточное, для нас основа финансовой стабильности – это ритмичность производства. У нас толкающая система, когда производство задает требования к тому, куда и как быстро должны «бежать» продажи, чтобы сбыть всю эту продукцию. Мы не можем временно остановить завод – нам это обойдется гораздо дороже, чем напрячь отдел продаж и заставить их продавать продукцию – хотя бы куда-нибудь за рубеж. Когда завод должен работать любой ценой – у нас совершенно другая система планирования.

Это второй фактор, который будет влиять на требования к автоматизации планирования.

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

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

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

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

• Но кадровое планирование – это опять финансы (затраты на ФОТ) и так далее.

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

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

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

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

Противоречивые требования

Для начала вторая история.

Предприятие – обычный постсоветский НИИ.

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

Объекты автоматизации:

• Обеспечение потребностей производства и НИОКР, которые закупают для своей деятельности различные компоненты.

• Также на балансе находятся здания, помещения, сооружения, для которых нужно «закупать» услуги энергообеспечения и поддерживать процессы эксплуатации. Например, есть гостиница для приезжих, оставшаяся с постсоветских времен, детские садики, спортивные центры – все это тоже влияет на планы закупки.

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

Возникает целый пласт методологических требований:

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

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

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

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

А если мы начнем настраивать по точечным запросам наших отдельных бизнес-пользователей: финансовая служба хочет своё, НИОКР хочет своё, гостиница хочет своё – у нас начнутся противоречивые требования, и система просто не взлетит.

Помимо функциональных требований, возникают нефункциональные требования – они вроде как не связаны с автоматизацией, но они критичные. Сюда относятся:

• Драйверы и сценарии планирования.

• Виды планов, ограничители по разным видам планов.

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

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

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

• И еще много-много того, что к автоматизации прямого отношения вроде как не имеет. И это спорная территория.

Мы, конечно, ожидаем, что заказчик нам принесет это в готовом виде. А заказчик ожидает, что мы придем как эксперты по планированию, и с учетом нашего опыта расскажем, как это должно быть – в ERP же заложены best practice… Возникают нюансы.

Как работать с требованиями к планированию

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

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

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

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

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

  • у производства свои представления о производственном планировании – какие данные и в каких разрезах будут в его рамках учитываться;

  • у закупок, которые должны закупать материалы под план производства, эти представления совершенно другие;

  • у планово-экономического отдела, который всю себестоимость по этим затратам потом будет собирать – третьи.

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

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

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

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

Теперь поговорим о том, как это делается.

Сегментирование процессов – как мы «едим слоника по частям».

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

• Если у нас цель проекта – повышение эффективности управления закупками, у нас основные процессы планирования – это закупки.

• Если у нас цель проекта – повышение эффективности производственного планирования, для нас основные процессы – это процессы производственного контура. И так далее.

Основные процессы:

• Мы анализируем в полном объеме.

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

• Основные процессы в контуре могут иметь вариативность – это то, что называется модификации. Например, у нас не один процесс планирования закупок, а несколько разных, потому что разная закупаемая номенклатура планируется по-разному: по разным основаниям, из разных источников данных и так далее:

  • есть планирование закупок для производства,

  • планирование закупок для продаж,

  • планирование закупок оборудования, ТМЦ для подготовки производства и т.д.;

  • планирование закупок для общехозяйственных ТМЦ;

  • планирование под ремонт производственного оборудования;

  • планирование инвестиционного характера и т.д.

Сколько видов закупок нужно в контуре проекта учесть – столько видов планирования у нас будет.

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

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

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

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

• Если мы понимаем, что смежные процессы сейчас полностью в контур автоматизации не влезают, то ставим условно говоря «временные заглушки». Идем в отдел продаж и говорим: «Сейчас у нас контур проекта ограничивается планированием производства – план продаж мы не автоматизируем. Вы должны нам выдать данные о планируемых продажах в Excel в таком-то формате». Фиксируйте и держите контур проекта, ограничьтесь простой загрузкой входных данных, иначе вы ввяжетесь еще и в автоматизацию планирования продаж – тогда проект сразу же начнет разрастаться.

Как оценить контур проекта?

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

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

Классический CJM – это взаимодействие клиента с компанией и внешней средой при удовлетворении своего запроса.

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

CJM – это один из возможных подходов. Это не новация, не волшебная пилюля – это одна из методик, как можно работать с требованиями.

Второй момент – мы должны провести двухуровневый анализ процессов.

• Мы должны провести классический анализ процесса с точки зрения действий – потоки действий, потоки работ и объекты/документы, которые при этом используются.

• И отдельно должны проанализировать потоки данных и их трансформацию.

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

• когда, кем и какой реквизит заполняется данными;

• в какой момент эти данные анализируются и подтверждаются;

• когда эти данные каким-то образом трансформируются, дополняются и так далее.

Таким образом мы проверяем, как у нас данные движутся по процессу.

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

Модель SIPOC – один из самых известных и простых подходов для двухуровневого анализа процесса через понятия поставщики/потребители и входы/выходы процесса.

Теперь поговорим о том, как гармонизировать требования.

Есть технология гармонизации требований – так называемое перекрестное интервью.

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

• Потом проверяем полученную информацию на непротиворечивость – на стыках поставщиков/потребителей.

Например, производство вам в процессе говорит: «Мы получаем для планирования производства план продаж», вы приходите в отдел продаж, спрашиваете: «Вы эти данные даете? Покажите, в каком формате вы их даете».

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

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

Мы должны проверить требования к данным по следующим критериям:

• насколько они у нас сопоставимы;

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

• и есть ли какая-то неудовлетворенность в этой зоне. Если есть – запускаем кросс-функциональные группы.

Кросс-функциональные группы – это процедура, когда мы собираем вместе совещание из поставщиков и потребителей, говорим: «Ребята, у вас несоответствие. Вы говорите, что это так, а вы – что по-другому. Договаривайтесь».

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

Как только они договорились, составляем:

• протокол встречи, проектное решение – как в итоге будет работать процесс: по порядку действий, методологии выполнения, выходным результатам и так далее;

• и дальше запускаем это уже в ТЗ по настройке модели в информационной системе.

На выходе у нас получаются следующие документы:

• Детальная карта процесса с описанием всех действий и правил их выполнения.

• Фиксация всех требований к входным/выходным данным процесса.

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

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

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

Дальше мы можем отдельно и более детально зафиксировать требования к НСИ – для устранения «ничейных зон».

Составляем реестр НСИ и детальные требования к НСИ, где мы описываем:

• что это за НСИ (справочник или фиксированный список);

• справочник линейный или иерархичный, как организована иерархия;

• какие у этого справочника есть реквизиты;

• какие для этих реквизитов источники данных;

• является ли справочник поставщиком данных для реквизитов другого справочника – тогда у нас возникают связи между НСИ.

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

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

Такой же подход применяется при формализации требований к отчетности:

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

• источник начальных данных;

• правила заполнения и группировки данных отчета;

• формулы расчета показателей.

Указываем для отчета:

• периодичность формирования;

• кому этот отчет должен поступать – у отчета может быть много потребителей;

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

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

Еще один инструмент, который используется для формализации требований – матрица интеграции. Он нужен, когда для автоматизации используется не одна система, а несколько. Когда процесс планирования сквозной, и мы не можем его провязать только в ERP.

Например, мы автоматизируем планирование производства и финансов – у нас ERP плюс «Управление холдингом». Или мы автоматизируем планирование ремонтов оборудования и производство – у нас ERP плюс ТОиР, и так далее.

В этом случае у нас возникает матрица интеграции, где мы должны описать:

• входные данные;

• выходные данные;

• система отправитель, из какого объекта системы эти данные попадают;

• система получатель, в какой объект системы эти данные поступают;

• правила передачи данных: онлайн или по регламентному заданию и так далее.

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

В той же матрице интеграции нужно определить какая система является первоисточником НСИ и как это потом должно транслироваться в другие системы, если у нас сложная ИТ-архитектура.

Такая форма позволяет четко и детально зафиксировать требования к интеграции.

Об этих инструментах и как с ними работать я подробно рассказываю на курсе по работе с требованиями.

Кто такой Архитектор, и зачем он нужен в проекте

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

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

Возникает та самая роль Функционального архитектора.

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

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

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

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

Архитектор – это отдельная роль, потому что на больших проектах это очень трудоемкая работа, это практически всегда Full time – 100% загрузка, особенно на этапе сбора требований и моделирования. Если проект небольшой, эту роль можно совмещать с ролью ведущего аналитика или руководителя проекта. Но в больших проектах, где в периметре 3 и более сложных подсистем, более 5 аналитиков – это выделенная функция.

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

Вопросы

Какие информационные системы вы используете для управления массивом проектной информации? Word, Excel или какие-то специализированные?

Я в основном использую Word, Excel, потому что все с ними работают. Есть коллеги, которые для моделирования процессов и фиксации требований используют Business Studio или другие специализированные решения.

Средств очень много. Есть СППР, который тоже позволяет фиксировать требования.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах". Также предлагаем посмотреть мастер-класс.