Обилие предложений на рынке программного обеспечения зачастую западного производства может сформировать ошибочную картину, что в России нет собственных разработок. Это далеко не так, более того российский рынок корпоративных информационных систем представлен не только линейкой продукции от 1С. Всеобъемлющее присутствие международных вендоров в стране, используемые ими маркетинговые трюки и искусственное прививание привычек, притормозили и увели в тень российские разработки. Наступает время, когда компании вынуждены идти по пути импортозамещения, даже те, кто отделился от глобальных корпораций и локализовался.

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

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

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

В данной работе мы выполним анализ примеров построения ресурсного плана в проектах внедрения ERP-систем, что позволит планировать человеческие ресурсы более точно и обеспечит более эффективное и качественное имплементирование программной системы. Для начала более подробно разберемся, как взаимосвязаны между собой три плана: проекта, ресурсный и затрат. Обычно план проекта ведется в разрезе задач, далее на него налагается ресурсный план, показывающий, какое число человеческих ресурсов требуется для выполнения активностей. Зная число и квалификацию ресурсов, а также их ставки, возможно рассчитать план по затратам. Таким образом все три плана связаны между собой и изменение одного из них непременно приводит к обновлению других. Наконец, построив ресурсный план, мы фактически формируем планы проекта и затрат.

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

Сегодняшняя ситуация вокруг спецоперации в Украине и последовавшие рестрикции со стороны европейских стран и США обнажили и без того известные проблемы импортозамещения западной продукции. Не исключением в этом вопросе стало программное обеспечение (далее – ПО), о старте импортозамещения которого заговорили еще в 2016 года. По изначальному плану замещение программного обеспечения должно было завершиться в 2024 году. Однако, не смотря на столь амбициозный план, ощутимых результатов это не дало как несколько лет назад, так и сейчас. Да, конечно, на протяжение всего этого времени публиковалось множество материалов на тему успешного замещения части западного ПО отечественным, однако это была лишь каплей в море ИТ-решений и технологий.

Последовавший в начале 2022 года уход из России практически всех известных вендоров от Microsoft, до SAP и Oracle, показал нашу сильную зависимость от прививаемого годами зарубежного ИТ-сервиса. По существу, начало полноценного замещения зарубежного ПО началось именно с этого момента, когда российские компании поставили перед фактом остановки поддержки, продления лицензий и работы самого ИТ-решения. Большинство ИТ-менеджером и директоров судорожно стало думать о переходе на российские аналоги, в частности на продукты 1С, как базового корпоративного решения. Однако, использование нового ПО на предприятии возможно лишь после его имплементирования, процесс которого оказался также сильно завязан на страны запада.

В это статье мы рассмотрим вопрос импортозамещения приложений класса ERP и ERP2, принимая во внимание тот факт, что это далеко не единственный компонент корпоративной информационной системы (далее – КИС). Для целей удобства повествования термины программное обеспечение, информационные и корпоративные системы, а также ERP-системы для нас будут тождественны. В работах [1-2] выделяют четыре основных уровня задач для внедрения КИС, к которым относят процессы, данные, приложения и технику, а также два вспомогательных: управление проектном и изменениями. Собственно говоря, процесс внедрения и импортозамещения ERP-систем мы будем рассматривать сквозь указанные 6-ть параметров.

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

В Советском Союзе в 1948 г. проблемы развития вычислительной техники становятся общегосударственной задачей. Были развернуты работы по созданию серийных электронно-вычислительных машин ЭВМ первого поколения (термин ЭВМ вместо «компьютер» употреблялся вплоть до конца 1980-х гг.).

Первыми изобретателями компьютера в СССР являются И.С. Брук и Б.И. Рамеев, совместно разработавшие проект цифровой ЭВМ с жестким программным управлением. В декабре 1948 г. они получили авторское свидетельство на изобретение «Автоматической цифровой машины».

«МЭСМ» (малая электронная счетная машина) – первый компьютер в СССР и в целом в континентальной Европе, была создан в 1951 г. под руководством С.А. Лебедева. Под его же руководством в дальнейшем были разработаны и сконструированы машины серии «М» (М-1, М-2 и другие ее модификации), из которых М-20 в 1960-х гг. была признана в СССР лучшей из отечественных машин. Специализированные ЭВМ, созданные под руководством С.А. Лебедева для системы противоракетной обороны, стали основой достижения стратегического паритета между СССР и США во время холодной войны.

В 1950 г. в Институте точной механики и вычислительной техники (ИТМ и ВТ) был организован отдел цифровых ЭВМ для их разработки и создания. В 1951 г. там была спроектирована машина БЭСМ (большая электронная счетная машина), а уже в 1952 г. началась ее опытная эксплуатация.

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

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

Информационные системы (ИС), являясь составляющей частью информационной инфраструктуры, представляет собой систему обработки информации совместно с соответствующими организационными ресурсами (человеческими, техническими, финансовыми и др.), обеспечивая ее распространение (ISO/IEC 2382:2015). ИС предназначена для своевременного обеспечения людей надлежащей информацией, то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция: документы, массивы данных, базы данных и информационные услуги. По охвату задач информационные системы можно классифицировать на персональные, групповые, корпоративные, системы органов власти и государственных учреждений [1].

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

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

Существует ошибочная точка зрения, что наиболее критичным этапом внедрения ERP-системы является разработка, это не совсем так. Немаловажны активности, связанные с тестированием, обучением и миграцией данных. Однако все это задачи, выполняются на стороне заказчика. В проект имплементации корпоративной информационной системы вовлечены и прочие заинтересованные стороны, в честности контрагенты [1]. Несмотря на то, что вопрос перехода к продуктивному использованию системы является ключевым в ходе запуска, его важность иногда недооценивается. По крайней мере, до тех пора пока вы не столкнетесь с Cutover’ом вплотную. Да, да, именно так называют план перехода в среде технических специалистов.

План перехода включает в себя ряд активностей, выполнение которых решает две основные задачи: техническая подготовка программного решения для функционирования в режиме реального времени, а также взаимодействие с клиентами и поставщиками для обеспечения непрерывной работы с ними. Cutover-план затрагивает технические, бизнес и вопросы, связанные с историческими данными [2]. Формирование плана перехода начинается много раньше промышленного запуска, так как задача в первую очередь требует большого вовлечения сотрудников заказчика, во-вторых, сильно зависит и влияет на технические активности смежных команд.

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

Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1].

Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2].

Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

Агрессивная, навязчивая реклама товаров, работ, услуг, продвижения бренда в PR-технологиях и маркетинге компаний сегодня начинает давать «обратный» эффект и со временем в таком формате уйдет в прошлое. Новой технологией подачи информации становится сторителлинг, который активно используется как коммуникационный метод продвижения бренда. Сегодня выделиться в огромном количестве информации в информационном потоке стало намного сложнее, поэтому сторителлинг – один из способов это сделать. Сторителлинг (Storytelling) – термин, употребляемый маркетологами, журналистами, психологами, преподавателями и понимаемый как коммуникативная технология, позволяющая посредством нарратива сделать информацию интересной и запоминающейся для адресата. Технология сторителлинга, или рассказывания историй, за последние несколько лет приобрела заметную популярность; она используется в различных профессиональных средах. Изначально сторителлинг был успешно внедрен и апробирован Дэвидом Армстронгом как инструмент управления персоналом. Затем этот метод  начал активно использоваться в маркетинге, PR, журналистике, образовании. 

В маркетинге и в PR-технологиях он помогает брендам выстроить прочные взаимоотношения, как с внешней, так и с внутренней аудиторией, эффективно сочетая рациональный и эмоциональный контекст. Это такой маркетинговый приём, использующий медиа-средства с целью передачи информации и транслирование смыслов посредством рассказывание историй с целью обеспечения эффективной мотивации к требуемому от субъекта действию. Он позволяет сохранить, систематизировать и донести информацию об основных достижениях, обосновать право считаться лучшим, важным и заслуживающим доверия, мотивировать, вызвать стремление к продолжению общения и сформировать лояльность субъекта. Этот рассказ захватывает внимание с первой секунды и держит его на протяжении всей истории, вызывая у читателя или зрителя симпатию к главному герою истории и, таким образом, доносит до него основную мысль. Сторителлинг оказывает воздействие путем понятного и простого намека. Воздействует на сознание людей, внушает им требуемые мысли, формирует сопричастность, вызывает запланированную реакцию и последующее поведение. Он становится всё более популярным форматом для коммуникации брендов с потребителями благодаря большой вовлечённости аудитории и укрепления доверия к спикеру. 

Внедрение корпоративных информационных систем позволяет автоматизировать большинство административно-хозяйственных операций предприятия. Класс системы, например, ERP, ERP2 или MRP, специфицирует бизнес-процессы, подлежащие автоматизации. Имплементация ERP-систем затрагивает две ключевые области деятельности компании: логистику и финансы. Причем специфика страны накладывает свой отпечаток: в Европе преимущественно акцент делается на логистических операциях, в России, напротив, – финансовых [1]. Для обеспечения эффективной работы ERP-системы необходимо обеспечить разумный баланс между логистическими и бухгалтерскими требованиями, их реализацией в программной системе.

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

Следует отметить, что, несмотря на кажущуюся простоту закупок, процесс ее отражения в ERP-системе достаточно непрост. Существуют различные виды закупок, каждая их которых имеет свои отличительные особенности и требует уникальной реализации в программной системе [2]. Зачастую в проектах внедрения ERP-систем цепочки закупок имеют сложную реализацию из-за необходимости удовлетворения бухгалтерским требованиям. Давайте рассмотрим схемы закупок, точки интеграции с финансовыми операциями и найдем способ их отражения в ERP-системе.

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

Несмотря на важность вопроса мигрирования данных корпоративных информационных систем, литературных источников, дающих исчерпывающее представление о переносе информации не так много. Но даже в них есть изъяны: или слишком поверхностное описание, или излишняя детализация, исключающая стратегию как таковую. Примером первой категории работ служит статья [1], повествующая о миграции данных в SAP ERP, однако тонкости и детали переноса основных и переменных данных в ней не раскрыты. Прочие работы [2-3] дают максимум информации по автоматизированным средствам переноса данных в той же системе SAP, хотя взаимосвязь между техническими средствами и концепцией, стратегией, видением не прослеживается. Все это подчеркивает необходимость детального анализа миграции данных ERP-систем, что особенно актуально для транзакционных информационных систем.

Одной из наиболее трудоемких составляющих в ведении бухгалтерского учета является внесение закрывающих документов от поставщиков (в просторечии именуемых «первичкой»). Это в частности акты оказанных услуг, товарные накладные, УПД (универсальные передаточные документы), счета-фактуры и многие другие, а также ряд более узко ориентированных документов, например, формы КС в строительной сфере. Все эти «оправдательные документы» критически важны как для бухгалтерии и налогового учета (в части принимаемых к учету расходов), так и для сотрудников, занятых продажей, поскольку даже при фактическом наличии товара (или его комплектующих и/или полуфабрикатов) без их внесения в базу (будь то 1С или аналог) ПО зачастую не позволяет произвести реализацию товара покупателю. Бывают и исключения, когда, например, в базе отключен контроль учета отрицательного остатка. Однако это имеет и свои риски в учетных ошибках, пересортице и возникновению неточностей в реальных складских остатках.

Чем больше объемы продаж или производства, тем больше требуется для этого документации. Если, например, прибор собирается из нескольких десятков деталей, которые приходят от разных поставщиков и при этом различными отгрузками, то для правильного расчета себестоимости одной продажи приходится вносить в учет большое количество закрывающих документов. Таким же сложным может быть и процесс «формирования» единицы товара в сфере услуг, например, в общепите, где на изготовление одного продукта порой нужны ингредиенты от разных поставщиков/изготовителей. И если для повара на кухне салат – это всего лишь одно блюдо, то для бухгалтера это может быть несколько разных документов, необходимых для «комплектации единицы готовой продукции», без которых неверно формируется себестоимость, что может привести либо к занижению налоговой базы (смертный грех в глазах фискального ведомства), либо к завышению (непростительно уже для собственников бизнеса).

Прежде всего, определимся с терминами. Что такое аудит? Это проверка бухгалтерской отчетности юридических (в отдельных случаях и физических лиц) на предмет достоверности данных. Причем эти данные должны соответствовать как показателям бухгалтерских регистров в электронной базе (например, та же 1С), так и сведениям из первичных документов [1].

Осуществлением аудита занимаются представители профессии под названием «аудитор». Этапы процесса проведения аудиторской проверки показаны на рис.1.

Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы.

Определение 1. Корпоративная информационная система (КИС) – это расширяемая информационная система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний, а также корпораций, требующих единого управления [2].

К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы [3-5], либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.

Информация определяется как сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления [1]. Объектом правового регулирования могут быть конкретные формы существования информации: 

Миграция данных является одним из ключевых и самых сложных аспектов внедрения SAP: непродуманная стратегия может поставить под угрозу весь проект. Несмотря на то, что миграция данных является частью плана по внедрению (Cutover Plan), её важность очень часто недооценивают и весь процесс рассматривается как простая административная задача по переносу данных из одного места хранения в другое. Команда сосредотачивается на дизайне и демонстрации системы (Workshop), а также конфигурации, оставляя планирование миграции на потом. В результате на активности по миграции закладывается недостаточно времени и ресурсов, что может привести к срывам сроков при запуске. Грамотно спланированные миграционные активности помогут избежать «кранча» в период подготовки, а также снизят риски после запуска проекта. 

Если целью внедрения SAP ERP является замена старой (Legacy) системы, то миграция позволит перенести релевантные бизнес-данные из Legacy в соответствующие SAP-модули. Процесс миграции включает в себя следующие этапы [1]:

История дизайн-мышления (design thinking) началась более полувека назад, когда Герберт Саймон озвучил идею дизайн-мышления в 1969 году в книге «Науки об искусственном» (The Sciences of the Artificial). В своей работе он привёл тезис об общности творческого подхода к различным видам деятельности, будь то написание музыкального произведения или, например, разработка техники [1].

В 70-80-х годах прошлого века этот подход проникает в менеджмент. В 1978 году Дэвид Келли создаёт вместе со своим университетским другом Дином Хови компанию Hovey-Kelley Design, которая в последствие станет ядром компании IDEO, сделавшей своей официальной доктриной дизайн-мышление [2]. Сотрудники IDEO учат своих клиентов думать, как дизайнеры, чтобы улучшить качество работы. В портфолио компании разработка Palm V, первой мыши для Apple, первый ноутбук [3, 4].

Позднее идею развили учёные Стэнфордского университета и основали в 2005 году Стэнфордский институт дизайна, или d.school, который продвигает идею дизайн-мышления [5]. Своей целью институт ставит построение методов, которые позволят развить навыки креативности, применимые к самым разнообразным областям. Для этого применяемся инструмент «радикального сотрудничества», когда студентов с разных факультетов, а также преподавателей и практиков из совершенно разных областей объединяют вместе [6]. Цель такого эксперимента обеспечить многообразие точек зрения на одну и ту же проблему и привить умение смотреть на один и тот же вопрос с разных сторон.

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

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

Процесс закупки продуктов выглядит следующим образом: подразделения создают документы первичных потребностей, отражая в ERP-системе данные материалов, количества, плановую дату поступления, на основе которых в дальнейшем будет происходить списание этих продуктов. После того, как документы первичной потребности утверждены, они поступают на обработку функционала ППМ (планирование потребности в материалах). ППМ анализирует наличие потребности в материале, уже имеющиеся запасы на складах, а также будущие поступления. Как результат ППМ автоматически формирует заявки на закупку для недостающего количества. Созданные заявки служат основанием для закупки у внешнего поставщика. Более того может формироваться особый вид заявок, позволяющий выполнять перемещение с других складов компании.