Необходимо также составить список всех факторов, которые отличают ситуацию «на земле» (то есть в организации, для которой проектируется процесс) от ситуации «на небесах» (то есть от модели, которая использована в качестве «рыбы» или спроектирована как замысел, идея). Например, в этот список могут войти конкретные требования законодательства или корпоративные требования, оргструктурные ограничения, логистические конфигурации и т. п. Чем более детально и конкретно сформулированы факторы, которые надо учесть, тем лучше.
Затем мы должны отработать составленные списки, обычно сначала сценарный, а потом факторный. Сценарный сильно модифицирует дизайн модели, факторный чаще фокусируется на деталях. Добавляя сценарии к базовой модели, мы ищем точки, где процесс должен переключаться на ту или иную ветвь, и прорабатываем идеологию этих ветвей. Часто она повторяет общую идеологию базовой модели, являясь ее частным случаем. Например, закупка канцтоваров для офиса – как правило, весьма упрощенная процедура.
Полученная в результате модель последовательно правится путем отработки факторного списка (пункт за пунктом). Мы спрашиваем себя: как конкретный фактор повлияет на процесс? Например, проектируемая процедура должна быть реализована силами имеющегося подразделения, поскольку это зона его функциональной компетенции. Состав подразделения задан, надо конкретизировать процесс, используя имеющихся сотрудников в качестве исполнителей и предусмотрев при необходимости передачу информации, контроль исполнения и прочие детали.
Завершается адаптация тестированием модели. Мы оцениваем ее работоспособность при различных условиях и сценариях. И что особенно важно, проверяем, выполнена ли поставленная задача. Нужно ли что-то скорректировать? Как именно?
1.3.3. Риски проектирования в проектах инжиниринга
Не сформулирована задача на проектирование. Процесс разработан, но не удовлетворяет витающим в воздухе требованиям. Именно потому, что они витают, а не записаны на бумаге, которая мозолит глаза группе инжиниринга. Приходится проектировать заново, причем иногда не один раз, если причина неудовлетворенности не будет осмыслена и проговорена.
Отсутствие экспертов в группе инжиниринга. Это может произойти по разным причинам: решили обойтись без них, не нашли, не договорились, их нет в природе, найденные эксперты на деле оказались не экспертами и пр. Само понятие «эксперт», конечно, относительно: требуемый уровень экспертизы, например, тесно связан с задачей на проектирование. Чем сложнее задача, тем более высокий уровень требуется (а значит, тем меньше таких экспертов, тем они дороже и менее доступны). К счастью, на практике в большинстве случаев достаточным является, например, уровень экспертизы сотрудников, которые уже есть в распоряжении начинающего функционировать стартапа. Однако в любом случае кто-то должен брать на себя роль эксперта в группе проектирования, кто-то должен предлагать решения при всеобщем унылом молчании, кто-то должен вести группу по пути созидания процесса.
Отсутствие шаблона, прообраза, прототипа (то есть «рыбы») процесса. И здесь причины разнообразны: от «решили обойтись» до «не смогли найти» или «нашли, но не подошла». Это не всегда серьезная проблема, так как, например, при наличии эксперта можно обойтись его знаниями и наработками, создать шаблон на ходу. Тогда наличие прототипа под рукой – вопрос удобства и экономии сил и средств. Но если и эксперт отсутствует, то дело плохо в большинстве случаев.
Завышенные требования к результату. Разработка работоспособного процесса – обычно вполне решаемая задача. Но если планка в задаче на проектирование задрана слишком высоко, то вполне можно ожидать, что группа инжиниринга не справится. То есть не удастся разработать вариант, который группа сочла бы приемлемым. В большинстве таких ситуаций выясняется, что задача на проектирование была сформулирована с запасом без особых причин («а вдруг получится», «лучше – не хуже» и т. п.) и вполне может быть скорректирована так, что разработанное решение либо волшебным образом становится годным, либо требует небольшой доработки, чтобы соответствовать настоящей формулировке задачи.
Слишком высокая детализация. В проектах инжиниринга изначально, как правило, не требуется особая детализация. Процесс проектируется укрупненно и запускается в состоянии не очень точного понимания «мелочей». И уже первые реализации подсказывают практические пути к тому, как он должен быть выстроен. Тогда с некоторым запозданием делается допроектирование процесса до требуемого (например, регламентным документом) уровня. И наоборот, слишком детальное проектирование приводит к тому, что реализовать процесс в таком виде не удается, возникают ошибки, проблемы, которые не были видны в ходе проектирования, а на практике всплыли. В этом случае приходится вносить правки на ходу, но процесс в это время лихорадит.