Александр, архитектор 1С
На одном из проектов по автоматизации крупного производственного предприятия я занимался моделированием и построением бизнес-процессов «to-be». Задача стояла по выстраиванию процессов управленческого учета затрат и формирование финансового результата.
Когда работа подходила к концу, заказчик задал вопрос: «Что будет являться результатом выполненных работ?». Согласно договора, должны быть предоставлены описанные и прорисованные бизнес-процессы в нотации BPMN с привязкой к учетной системе 1С:ERP, а также реестр настроек и системный сценарий использования. Но заказчика не удовлетворил данный перечень. Он также хотел получить методику «управленческого учета затрат и формирование финансового результата», т.к. на одном из совещаний было об этом сказано. И действительно, на одном из совещаний были перепутаны слова «метод» и «методика», которые очень близки по созвучию, но имеют большую разницу в понятии и соответственно разный объем работ.
В чем отличие метода от методики
Метод — способ достижения какой-либо цели. В привязке к системе, методы все определены и описаны в документации к системе. Например, на страницах ИТС.
Методика — это, как правило, некий готовый «рецепт», алгоритм, процедура для проведения каких-либо нацеленных действий. Методика, формируется непосредственно для заказчика. В ней описываются готовые наборы справочников и их настройка. Для ее формирование требуется на порядок больше ресурсов.
На совещании должно было прозвучать, что для заказчика мы определим конечный перечень методов, а в прорисованном и описанном бизнес-процессе укажем какой метод в каких случаях должен применяться. В действительности было сказано, что будет разработана методика, содержащая перечень конечных методов и бизнес-процессы по их применению.
Все было бы хорошо, т.к. данный объем работ можно было применить к понятию «Методика», если бы мы зафиксировали, что данный набор действий конечный и другой информации содержать не будет. Но этого не было сделано. Заказчик понял, что это только часть методики, и в ней будут содержаться проработанные справочники «Статей расходов/доходов» с правилами закрытия. И он был прав, т.к. понятие «методика» не было зафиксировано.
Ситуация Win-Win
В сложившейся ситуации мне повезло, т.к. часть работы было сделано по другой задаче (в рамках бюджетирования мной были сформирован перечень cтатей бюджетов, расходов и доходов) и осталось только определить правила закрытия. Как следствие, мы согласились с заказчиком и пошли на их требования без увеличения бюджета проекта. Заказчик доволен, мы не потеряли маржинальность проекта — ситуация Win-Win.
Какие можно сделать выводы:
- Всегда фиксируйте ключевые понятия и уточняйте у заказчика, что нет двусмысленности.
Поделитесь в комментариях сталкивались ли вы на проектах с подобными ситуациями и как их решали?
Еще больше интересных тем, связанных с управлением, методами и инструментами работы, вопросами коммуникаций в проектах, — на нашем Telegram-канале