- -
- 100%
- +
Это совершенно разные задачи.
ERP-лабиринт начинается не там, где плохая программа
Разочарование в ERP нередко возникает уже после внедрения. Пользователи говорят, что система «не понимает нашу логистику», что приходится вести дополнительные Excel, что статусы не отражают реальную ситуацию, что одну заявку нельзя нормально связать с несколькими перевозками, что склад и транспорт живут отдельно, что финансовый результат появляется слишком поздно.
Иногда причина действительно находится в функциональности или настройке системы.
Но иногда программа просто получила на вход модель, в которой сама предметная реальность предприятия не была разделена.
Если потребность, заявка, отправление, схема доставки, маршрут, услуга, задание и рейс сведены в один объект, никакая дополнительная кнопка не превратит этот объект в полноценную архитектуру. Максимум он станет ещё более сложным документом.
Сначала нужно восстановить объёмную модель.
И лишь затем определить, какими программными носителями она реализуется.
Из одной заявки получается карта предприятия
Транспортная логистика особенно хорошо показывает фундаментальную проблему ERP-проектов. Предприятие существует не как набор экранов и не как набор подразделений. Оно существует как система взаимосвязанных бизнес-предметов, которые меняют состояния, переходят между процессами, получают доказательства и в определённых точках пересекают границы предметных областей.
Продажа создаёт основание для одной транспортной потребности. Закупка — для другой. Производство зависит от своевременности внутренних перемещений. Склад должен получить понятное транспортное требование и вернуть подтверждение готовности. Автопарк предоставляет ресурс. Внешний перевозчик — услугу. Финансовый контур получает стоимость и подтверждённые документы. Качество — отклонения и доказательства. Международный или специальный режим подключается только тогда, когда для этого возникло подтверждённое условие.
Так отдельная «заявка на перевозку» оказывается входом в гораздо более крупную архитектуру.
Не потому, что кто-то специально усложнил логистику.
Она такой была до автоматизации.
Как выйти из этого лабиринта
Когда проект уже накопил десятки интервью, несколько версий BPMN, таблицы требований, документы ERP, схемы интеграций и противоречащие друг другу представления подразделений, попытка нарисовать ещё одну «общую правильную схему» обычно только увеличивает объём лабиринта.
Следующий шаг другой.
Сначала определяется предметный охват проекта. Затем восстанавливаются бизнес-предметы и их таксономические паспорта, различаются их состояния и жизненные циклы, фиксируются процессные роли предметов и междоменные передачи. После этого границы бизнес-процессов перестают зависеть от того, как называется отдел или документ в системе. И только затем предметная архитектура связывается с ERP, TMS, WMS, электронным документооборотом и необходимыми расширениями.
В транспортной логистике разница хорошо видна уже на одном примере: транспортная заявка действительно нужна — просто она не обязана изображать собой всё предприятие.
Если проект уже утонул в интервью, документах и противоречащих схемах, следующий шаг — не рисовать ещё одну схему. Нужно определить предметный охват и восстановить архитектуру проектного baseline: какие предметы существуют, где проходят их жизненные циклы, какие процессы ими управляют и что именно должно быть реализовано в прикладных системах.
В этом месте лабиринт впервые получает карту.
Транспортная логистика также показала, что физическое движение редко начинается внутри самого транспортного контура: основание приходит из продажи, закупки, производства или сервиса. Чтобы увидеть, как формируется одно из таких оснований, нужно перейти от перемещения результата к внешнему обязательству по его получению. В закупках эта граница проходит особенно наглядно: потребность, заявка, выбор поставщика, договор, заказ и поставка связаны одной хозяйственной целью, но не являются состояниями одного предмета.
Глава 4. ERP-лабиринты: автоматизация закупок — заявка на закупку ещё не закупка
Почему согласованная заявка, выбранный поставщик, заказ, поставка и приёмка не образуют один большой «процесс закупки»
Закупки кажутся очень удобной областью для автоматизации, потому что на поверхности у них есть почти идеальный документ-центр. Предприятию что-то понадобилось, сотрудник оформил заявку, руководитель её согласовал, отдел закупок нашёл поставщика, сформировал заказ, дождался поставки, склад принял товар, бухгалтерия оформила поступление, казначейство заплатило — и закупка закончилась. Если эту последовательность аккуратно разложить по дорожкам BPMN, получится вполне профессиональная схема, в которой каждый участник узнает собственную работу.
В прикладной системе эта конструкция выглядит ещё убедительнее. В документации 1С: ERP редакции 2.5 прямо предусмотрены отдельные документы «Заявка на обеспечение» и «Заявка на закупку», механизмы согласования, передачи на выполнение, формирования заказов поставщикам и контроля исполнения. Причём сама документация специально разделяет момент возникновения и согласования потребности и последующий выбор поставщика с формированием заказов.
Казалось бы, вопрос решён. Нужно только перенести эту логику на предприятие.
Но именно здесь начинается очередной ERP-лабиринт.
Первая попытка: провести заявку через всю закупку
Первая схема обычно получается очень понятной. Инициатор создаёт заявку на закупку, руководитель её согласует, закупщик уточняет номенклатуру, цены и условия, запрашивает предложения, выбирает поставщика, заключает договор, оформляет заказ, контролирует поставку, передаёт документы на склад и в бухгалтерию, после чего заявка закрывается.
Схема выглядит даже лучше, чем аналогичная схема продаж или ремонта, потому что слово «закупка» действительно сопровождает почти весь маршрут. Человеку нужен материал — он формирует заявку на закупку; закупщик по ней работает; поставщику направляют заказ; в конце предприятие получает требуемый материал. Интуитивно кажется, что это один предмет, который просто проходит разные стадии.
Проблема появляется, если перестать следить за документом и спросить, что именно существует в каждом участке этого маршрута.
До заявки уже должна существовать закупочная потребность — подтверждаемая необходимость получить определённый товар, работу, услугу или результат кооперации в заданном количестве и к определённому сроку. Эта потребность может возникнуть из производственного плана, ремонтного задания, клиентского заказа, дефицита запаса, инвестиционного проекта или другой хозяйственной причины. Она ещё не является заявкой и тем более не знает поставщика.
После оформления появляется другой предмет — заявка на закупку, то есть внутренний управляемый запрос организовать закупочное обеспечение одной или нескольких потребностей. Затем может возникнуть план закупок и отдельная позиция плана. Потребности группируются, формируются требования, появляется лот. После этого начинается закупочная процедура, поставщики направляют предложения, предложения оцениваются, принимается решение о выборе. Потом возникают договор, закупочное обязательство, заказ поставщику, график поставки и, наконец, сама поставка.
Это не статусы одного документа. В предметной модели закупок они специально разделены как самостоятельные управляемые сущности с разной идентичностью и собственными жизненными циклами. Например, закупочная потребность прямо отделена от заявки, плана, лота, договора и заказа; заявка на закупку — от самой потребности, плана, лота и заказа поставщику.
Пока этого различения нет, заявка начинает незаметно менять смысл. Сначала она означает «нам это нужно», потом «это разрешено покупать», затем «по этому надо искать поставщика», дальше «мы выбрали поставщика», потом «мы ему заказали», а в конце — «поставщик всё поставил». Название объекта остаётся прежним, но хозяйственная реальность внутри него несколько раз полностью меняется.
Даже 1С: ERP фактически предупреждает об этой ловушке
Здесь возникает интересный момент. Иногда предметное разделение воспринимается как искусственное усложнение, которое методолог навязывает прикладной системе. Но в закупочном контуре сама 1С: ERP уже показывает противоположное.
В документации по заявкам прямо указано, что потребность можно сформировать при ещё неизвестном поставщике и ориентировочной цене, согласовать её до выбора поставщика, затем передать в закупки и только после этого формировать заказы поставщикам. Более того, заказ поставщику создаётся по отдельным строкам заявки после её передачи на выполнение, а состояние заявки позволяет отслеживать, какие позиции уже заказаны, а какие ещё остаются открытыми.
То есть даже на прикладном уровне система различает как минимум несколько моментов, которые в примитивной BPMN-схеме обычно склеиваются в один: возникновение потребности, её согласование, работу закупщика с условиями и поставщиками, создание заказов и дальнейшее обеспечение.
Предметная модель идёт просто ещё глубже. Она задаёт вопрос не только о том, какой документ появился в программе, но и о том, какой управляемый предмет возник, изменился или был передан дальше.
Вторая попытка: добавить на схему весь завод
Когда первой схемы становится недостаточно, аналитик действует вполне логично: он начинает подключать соседние подразделения.
Производство сообщает, откуда появляется потребность в сырье и комплектующих. Планировщики требуют показать годовой и оперативный планы закупок. Склад напоминает, что часть потребностей вообще можно закрыть имеющимся запасом. Технические специалисты хотят отдельно согласовывать характеристики приобретаемого оборудования. Качество требует входной контроль и правила работы с несоответствующей поставкой. Юристы добавляют договор и спецификацию. Казначейство — оплату. Бухгалтерия — приобретение и расчёты. Транспортная логистика — доставку от поставщика. Если закупка внешнеторговая, появляются разрешения, валютное обязательство, таможенные и логистические ограничения.
Потом возникает ещё один слой: работа с самим поставщиком. Его нужно зарегистрировать, проверить, квалифицировать, возможно аккредитовать, а после нескольких поставок — оценить по фактическим результатам.
Следующий эксперт просит показать запрос предложений, коммерческое сравнение и переторжку. Ещё один — лотирование. Затем обнаруживается, что предложение поставщика и решение о выборе поставщика — не одно и то же. Договор может существовать без конкретного заказа, а рамочное соглашение — охватывать множество будущих заказов.
На одном листе постепенно оказываются потребность, заявка, план, лот, требования, поставщик, квалификация, процедура, предложение, оценка предложения, решение о выборе, договор, спецификация, обязательство, заказ поставщику, график, транспорт, платёж, поставка, партия, приёмка и расхождение.
Схема стала значительно полнее. Но предметные границы в ней обычно становятся ещё менее заметными.
В таких моделях очень легко перепутать глубину со сложностью рисунка. Аналитик действительно собрал множество реальных действий, но на общей схеме непонятно, где закончилась потребность и возникла заявка, где завершился выбор и появилось закупочное обязательство, что именно поставщик сейчас исполняет, а что склад потом принимает.
Процесс превратился в паутину не потому, что закупки слишком сложны. Он превратился в паутину потому, что несколько самостоятельных предметных траекторий попытались нарисовать как одну.
Заявка на закупку — плоская тень объёмной закупки
Представим сложный механизм, который освещён сбоку. На стене появляется его тень. Она вполне реальна и даже полезна: по ней можно понять общий контур, размер и положение объекта. Но внутри тени исчезают отдельные узлы, связи, глубина и устройство механизма.
Заявка на закупку в ERP-проекте часто становится такой тенью.
В ней действительно можно зафиксировать, что требуется приобрести, в каком количестве, к какому сроку, для какого подразделения и, позднее, на каких закупочных условиях. Документ может проходить согласование и исполнение, быть связан с поставщиками и заказами. В документации 1С: ERP заявка как раз используется для согласования потребности до выбора поставщика и последующего формирования заказов.
Но за одной заявкой находится объёмный предметный мир.
Потребность должна сначала возникнуть и быть подтверждена. Планирование должно определить, когда и каким образом она попадёт в обеспечение. Требования должны зафиксировать, что именно предприятие согласится считать приемлемым результатом. Лот определяет совместно выводимый на рынок состав. Закупочная процедура задаёт правила выбора. Поставщики создают предложения. Оценка предложения является отдельным доказательным результатом. Решение о выборе поставщика — отдельным управленческим решением.
Затем договор закрепляет условия. Закупочное обязательство фиксирует обязанность сторон. Заказ поставщику конкретизирует исполнение. График определяет временную структуру. Поставка показывает фактическое движение результата от поставщика. Приёмка отвечает уже на вопрос, соответствует ли полученное ожидаемому.
Свернуть всё это в одну заявку технически возможно.
Но это всё равно будет тень.
Предмет-драйвер здесь тоже не существует один
Правильное разделение не означает, что теперь нужно просто заменить «заявку» каким-нибудь другим главным существительным, например «потребностью», и объявить проблему решённой.
Конкретный бизнес-процесс действительно удерживается одним предметом-драйвером. Но этот предмет всегда находится в окружении других предметов, которые дают основание, обеспечивают движение, подтверждают результат, задают правила или передаются из соседнего процесса.
В процессе формирования закупочной потребности драйвером является сама потребность. Производственный план, ремонтное задание, заказ клиента или выявленный дефицит могут выступать её основаниями, но не превращаются из-за этого в закупочную потребность.
В процессе формирования заявки драйвером становится заявка на закупку, а подтверждённая потребность уже используется как вход и доказательное основание.
При планировании драйвером является план закупок. Согласованные заявки становятся материалом для его формирования.
При подготовке закупочной процедуры изменяется уже другой предмет — закупочная процедура, причём требования, лот, квалификация поставщиков и модель оценки играют собственные процессные роли.
Решение о выборе поставщика завершает один контур и становится основанием для договорного. Договор затем участвует в формировании закупочного обязательства. Заказ поставщику конкретизирует это обязательство. Фактическая поставка становится предметом следующего процесса.
В одном процессе предмет может быть драйвером, а в следующем — передаваемым, обеспечивающим или доказательным входом.
Вот почему предметная архитектура не распадается на независимые куски. Она собирается через точные передачи.
Зачем заявке на закупку нужен таксон
Как и в продажах, одно название документа здесь мало что говорит.
В одной компании «заявкой на закупку» называют первоначальное письмо снабжению. В другой — уже согласованную потребность. В третьей — документ, по которому закупщик должен получить три предложения. В четвёртой — практически готовый заказ поставщику.
Формально все произносят одинаковое слово. Предметно они говорят о разных сущностях.
Таксон нужен именно для того, чтобы удержать идентичность предмета независимо от названия формы и системы.
В принятой модели заявка на закупку определяется как внутренний управляемый запрос на организацию закупочного обеспечения одной или нескольких потребностей. Она не является самой потребностью, планом закупок, лотом или заказом поставщику. Её жизненный цикл начинается с черновика, проходит согласование и передачу в закупочную функцию, затем исполнение и заканчивается выполнением либо отменой; отдельно предусмотрен возврат на доработку.
Таксономический паспорт позволяет задать вопросы, которые невозможно решить простым наименованием документа. Какая подтверждённая потребность лежит в основании заявки? Можно ли объединить в одном экземпляре несколько потребностей? Какая версия заявки является действующей? Что именно означает согласование? Когда заявка считается переданной в закупки? Что служит доказательством её выполнения? Как отличить выполненную заявку от заказа, который поставщик ещё фактически не исполнил?
После таких вопросов становится видно, насколько опасна фраза «ну это всё у нас одна заявка».
Закупки не существуют отдельно от производства, склада и денег
У закупок особенно много соседей, потому что они сами по себе почти никогда не создают исходную хозяйственную потребность.
Производству нужен материал или комплектующее. ТОиР нужна запасная часть. Инвестиционному проекту — оборудование. Сервису — комплект. Продажам может потребоваться покупной товар. Планирование запасов фиксирует дефицит и необходимость пополнения.
Закупочная функция получает эти основания и отвечает уже за преобразование подтверждённой необходимости во внешний закупочный результат.
Но даже после этого она не становится владельцем всего дальнейшего движения.
Управление запасами решает вопросы покрытия потребности запасом и назначения обеспечения. Склад владеет физической приёмкой, размещением и движением полученных материальных объектов. Транспортная логистика организует перемещение поставки. Качество формирует результаты контроля и сведения о расхождениях. Казначейство исполняет платежи. Бухгалтерский и налоговый учёт отражают обязательства и хозяйственные события. В предметной модели эти границы проведены явно: закупки принимают и передают интерфейсные предметы, не присваивая себе внутренние решения соседних областей.
Это особенно заметно в конце поставки. Закупщик может контролировать, что поставщик подтвердил отгрузку и товар прибыл, но физическая приёмка на складе является другим контуром. Из него в закупки возвращается результат приёмки и, при необходимости, расхождение по поставке. Уже на основании этих предметов закупочная функция принимает свои решения — например, как дальше работать с поставщиком и обязательством.
Точно так же оплата поставщику не должна рисоваться внутренней процедурой закупщика только потому, что без неё поставка не состоится. Закупка формирует договорное и расчётное основание, но движение денежных средств принадлежит казначейству.
Граница не разрывает цепочку. Она объясняет, что именно пересекло эту границу.
Шесть предметных групп и тридцать пять предметов вместо одной заявки
Масштаб особенно хорошо становится виден, если посмотреть на закупки не через документы программы, а через предметную модель.
В ней выделены шесть предметных групп и 35 самостоятельных бизнес-предметов. Для них зафиксированы 253 состояния, 304 события и 35 жизненных циклов; отдельно определены представления, доказательства и функциональные назначения ролей.
Первая группа работает с самим поставщиком и подтверждением его способности к поставке: регистрацией, квалификацией, аккредитацией и оценкой.
Вторая удерживает потребность и планирование: закупочную потребность, заявку, план и позиции плана.
Третья раскрывает процедуру выбора: требования, лоты, процедуры, предложения, квалификационные заключения, оценки и отдельное решение о выборе.
Четвёртая отвечает за договорное закрепление: рамочное соглашение, договор, спецификацию, закупочное обязательство, его обеспечение и решения по договору.
Пятая сопровождает заказ и исполнение поставки: заказ поставщику, график и саму поставку, а на границах — партию, результат приёмки и расхождение.
Шестая добавляет специализированный внешний контур — разрешительные и валютные предметы внешнеторговой закупки.
Так выглядит предметный объём, который на пользовательском экране может быть спроецирован всего на несколько знакомых документов.
Двадцать один процесс вместо одного «процесса закупки»
Процессная архитектура показывает ту же область уже в движении. В ней шесть групп процессов, 21 бизнес-процесс, 126 процедур, 504 операции и 35 интерфейсов.
Первая группа из четырёх процессов управляет поставщиком: его регистрацией, квалификацией, аккредитацией и оценкой. Вторая, также из четырёх процессов, работает с потребностью и планированием — от формирования закупочной потребности и заявки до плана, требований и лота. Третья группа проводит закупочную процедуру и выбор поставщика: подготовка процедуры, получение предложений, квалификационная проверка участника и воспроизводимая оценка с отдельным решением о выборе.
Самая крупная четвёртая группа переводит результат выбора в договорное исполнение: рамочное соглашение, договор, решение по договору, закупочное обязательство, заказ поставщику и график поставки. Пятая группа контролирует фактическую поставку и обрабатывает вернувшиеся результаты приёмки и расхождения. Шестая накладывает специализированный внешнеторговый и валютный контур, не создавая параллельную копию всех предыдущих процессов.
На общей схеме каждый из этих блоков должен выглядеть самостоятельным процессом, а между ними должны идти не абстрактные стрелки «далее», а конкретные предметные передачи.
Именно этот рисунок должен стать главным визуальным ориентиром главы. Когда человек увидит рядом двадцать один процесс, он впервые физически почувствует разницу между фразой «создать заявку и купить» и реальной архитектурой закупочной деятельности.
При этом внутри каждого из двадцати одного процессов скрывается следующий уровень: процедуры, операции, роли, решения и доказательства. Их не нужно выводить на общую карту — иначе она снова превратится в ватманную паутину.
Общая схема отвечает на вопрос, из каких самостоятельных предметных изменений состоит область.
Детальная — как устроено одно из них.
Увеличим один процесс: формирование и согласование заявки на закупку
Вернёмся к предмету, с которого начинался наш лабиринт.
Процесс формирования заявки не начинается с создания строки в программе. До него уже существует подтверждённая закупочная потребность. В модели переход сформулирован прямо: подтверждённая потребность передаётся в процесс формирования и согласования заявки на закупку.
Предметом-драйвером теперь становится заявка на закупку.