деманд планирование что это
Demand & Supply. Единство противоположностей
Причиной большинства проблем, возникающих в любой системе, являются вовсе не внешние обстоятельства, на которые так хочется списать неудачи. Причина, как правило, кроется внутри системы, в собственных, не согласованных между собой действиях. Правая рука не знает, что делает левая, а в результате усилия расходуются на внутреннее трение. Думаю, что метафора двух человеческих рук для успеха бизнеса совсем не случайна, и стоит разобраться, какие две половинки бизнеса следует синхронизировать между собой.
Эволюционно управление бизнес-системами проделало путь от единых иерархий, через проектные и процессные матрицы к плоским мобильным структурам управления. Современный цифровой бизнес условно разделяет систему на часть, контактирующую с клиентом через мобильные устройства, и на инфраструктуру, обеспечивающую обработку событий, генерируемых самим же клиентом. О какой же левой и правой руке бизнеса мы говорим в базовом понимании и какова природа синхронизации этих двух половинок бизнеса?
А и Б сидели на трубе
Бизнес очень похож на классическую школьную задачу о бассейне, в который через трубу А вливается и через трубу Б выливается поток процессов. Но еще больше бизнес похож на открытую с двух сторон трубу переменного сечения, в которую внешний мир пытается «задуть» множество событий (рис.1). Сам же бизнес, являясь системой разумной, пытается уловить, привлечь к себе, отфильтровать и втянуть вовнутрь только важные и полезные события, преобразовав их на выходе в желаемые целевые результаты. Так что левую и правую части трубы я бы с легкостью назвал модными сегодня терминами Demand и Supply.
Рис. 1. Труба активностей. Половинки Demand и Supply.
Целью левой области, Demand, является определение потребностей бизнеса с учетом всех внешних и внутренних факторов. Целью правой области, Supply, является реализация этих потребностей. Поток внутри такой трубы активностей напоминает скоростной физический поток сжимаемого газа. Стенки трубы – это бизнес-правила, регламентирующие и ограничивающие потоки работ. Площадь сечения трубы – это участвующие ресурсы, своего рода энергия, которую бизнес расходует на выполнение процессов. Так что через сечение может пройти только ограниченный объем работ.
Чтобы тратить ресурсы эффективно, возникает жесткая необходимость регистрации, корреляции и ранжирования событий, поступающих на вход, для принятия качественных решений и пропуска в область Supply только упорядоченных потоков работ, которыми действительно есть смысл, желание или необходимость заниматься.
Такое разделение деятельности на Demand и Supply и есть базовое разделение зон ответственности людей в реальном бизнесе. Не на управленцев и подчиненных, не на бизнес и поддержку, а на сотрудников, смотрящих во внешний мир глазами бизнеса, и сотрудников, реализующих потребности бизнеса при текущих ограничениях.
Люди по своей природе склонны находиться преимущественно либо в реактивной аналитической, либо в проактивной созидательной области работ. Именно поэтому на рисунке 1 область Demand отмечена синим цветом и ассоциируется с фазой Check, а область Supply отмечена красным цветом и ассоциируется с фазой Plan классического цикла PDCA (Plan, Do, Check, Act).
Однако здесь кроется подвох. Грубейшей ошибкой было бы поставить знак равенства между Demand и реактивным состоянием Check, а также между Supply и проактивным состоянием Plan. Люди, работающие преимущественно слева или справа, занимаются разным, но самодостаточным делом и движутся в своем полном цикле деятельности PDCA. Похоже, что в рисунок 1 закралась неточность – цвет областей. Труба потоков работ не делится жестко на синюю и красную половины. Красный и синий цвета должны плавно проникать друг в друга. И именно в этом проникновении и кроется наибольшая сложность и секрет эффективности бизнеса.
Ведь в реальной жизни происходит именно так. У людей, разработавших проект в части архитектуры и требований, просто чешутся руки реализовать его самим, ну или по крайней мере поруководить процессом изготовления продукта. Те же, кто изготавливают продукт, считают, что лучше всех разбираются в предметной области, и их просто тянет, напрямую пообщавшись с клиентом, проигнорировать фазу анализа и проектирования, сразу бросившись делать дело. В разработке программных продуктов первая крайность порождает модель проекта Waterfall, вторая — доведенный до абсурда Agile. Недостатки обоих подходов хорошо известны.
А что же внутри трубы? Препарируем чуть подробнее ее продольный срез, задавшись вопросом, а нет ли еще одной базовой полярности в любом потоке процессов?
Наследственность и изменчивость
Извечный вопрос «Где заканчивается операционная рутина и начинается область развития и изменений» имеет извечный ответ: «Вы сами хозяин того, что считать изменением в архитектуре вашей системы». Нет точной границы, а есть плавный переход между стандартной, основанной на опыте деятельности Run и направленной на изменения в системе деятельности Change. В своих крайних состояниях Run представляет собой мгновенные автоматические системные операции, а Change – долгие проекты с большой неопределенностью. Подобно геному человека, Run несет ответственность за наследственность и повторяемость в бизнесе, а Change — за изменчивость и появление новых свойств.
Современный менеджмент давно уже рекомендует разделять области Run и Change как по способам управления, так и по составу участвующих в них людей. Так что мы имеем дело не с одной, а с двумя парами противоположностей, образующими квадрант базовых активностей любого бизнеса (рис. 2).
Рис. 2. Квадрант базовых активностей бизнеса
В направлениях Demand и Supply собираются люди, по своим психотипам нацеленные на внешнюю среду и на внутреннюю реализацию, а в направлениях Run и Change собираются люди, либо нацеленные на сохранение сложившегося порядка, либо стремящиеся этот порядок изменить. Так что модель трубы активностей можно уточнить. Предлагаю разместить скоротечную и зачастую автоматизированную деятельность Run вблизи оси, а медленную и нестандартную деятельность Change — по краям трубы активностей (рис. 3).
Рис. 3. Труба активностей. Разделение областей Run и Change
Выглядит немного необычно, но очень похоже на реальные физические явления, например на движение песка в песочных часах или движение вязкого газа в ракетном двигателе. Максимальная скорость потока достигается по оси, а минимальная вблизи стенок трубы. Необычность состоит в том, что Run на картинке представлен как цельный неделимый процесс, а Change искусственно разрезан на верхнюю и нижнюю полоски. Прежде чем объяснить, почему так, предлагаю посмотреть на модель еще чуть подробнее глазами департамента информационных технологий (рис.4).
Рис. 4. Как устроена труба активностей. Глазами ИТ.
Верхняя половина такого среза, подобно ресурсно-сервисной модели ITSM, ассоциируется с клиентскими сервисами. Нижняя половина смотрит на техническую инфраструктуру. Очевидно, что в близкой к оси области RUN многие процессы выполняются взаимосвязанно, зачастую автоматически, очень быстро пролетая сквозь трубу. В области Change, на периферии трубы, приходится отдельно прорабатывать изменения в сервисах для клиентов и отдельно связанные с ними изменения в инфраструктуре.
Каждая из областей Demand и Supply вдоль линии течения процесса делится на Front Office, контактирующий слева и справа с внешней средой, и Back Office, расположенный ближе к центру и выполняющий внутрисистемные операции. В качестве примера такого разделения могу привести, например, пары процессов ITSM – управление инцидентами и управление проблемами или управление изменениями и управление работами.
Внимательное изучение рисунка 4 дает также полезную информацию о том, как наиболее эффективно выстроить организационную структуру сложного современного ИТ-подразделения. Все просто! Подразделения ИТ естественным образом должны стараться повторять структуру потока работ в отдельных его частях.
На левой границе трубы во Front Office Demand поток структурируется по точкам контактов с внешней средой. Сверху — по клиентам и сервисам, а снизу — по сложившимся инфраструктурным технологиям.
Ближе к центру, в области Back Office Demand, поток переструктурируется в архитектуру предметной области компании, по технологиям уже работающих продуктов. В каждой отрасли — телекоме, медицине, банках у энергетиков, на транспорте архитектура предметной области своя. Именно поэтому подавляющее большинство сотрудников Demand – это бизнес-аналитики, архитекторы, менеджеры проектов и технические писатели, ведь основной продукт, создаваемый Demand – это проектные требования, а вовсе не сам конечный продукт.
В самом центре трубы находится сердцевина принятия управленческих решений. Структура и правила управления этой частью больше определяются искусством, чем наукой управления. Они уникальны для каждой компании. Это и есть бизнес. В самом центре лежит искусственный интеллект компании в виде автоматически выстроенных процессов принятия решений, в форме алгоритмов ИТ и действующих процедур. Чуть шире, эта область окружена областью принятия решений менеджерами в различных формах — от набора управленческих комитетов до единоличного принятия всех решений руководителем.
Далее, справа, в области Back Office Supply, поток переструктурируется в архитектуру изготовления и предоставления продуктов. Эта архитектура зависит не столько от предметной области, сколько от инструментария изготовления. Так, например, для создания современных ИТ-решений требуется собирать людей не по знанию банковского или страхового бизнеса, а по владению технологиями (разработчики Java, разработчики интеграционных сред, тестировщики и т. д.). Только в этом случае «фабрика Supply» становится «мобильной», не зависящей ни от состава временно привлекаемых ресурсов, ни и от конкретных заказчиков из Demand. Она может работать на Demand как внутри, так и вне компании, превращаясь из подразделения тратящего в подразделение, зарабатывающее деньги.
И наконец, крайняя область справа Front Office Supply полностью повторяет Front Office Demand, поскольку мы циклично возвращаемся к точкам контакта с клиентами и всем внешним миром.
Здесь можно было бы остановиться, если бы не одно но… Мне лично в такой модели долгое время не давал покоя разрыв потоков Change на верхний и нижний слои. Этот разрыв на практике соответствует разделенности людей и подразделений, называющих себя бизнесом, и теми, кто работает с ИТ-инфраструктурой. Эти люди изредка встречаются на совещаниях и часто не слышат и не понимают друг друга. В один прекрасный момент я понял, насколько детская ошибка лежит в невидении очевидного. Мы говорим о трубе событий, а в модели рисуем лишь ее продольный плоский срез. Но реальная труба ведь не плоская, а круглая! И стоит лишь понять, как она устроена в поперечном срезе.
Взгляд через подзорную трубу
Попытавшись взглянуть на всю модель слева, как в подзорную трубу, мы обнаружим целый калейдоскоп событий. Мы увидим вращение Demand и Supply с периодической сменой полюсов. Это вихреобразное движение хорошо описывается одним небезызвестным символом (рис. 5).
Рис. 5. Поперечный срез трубы активностей (область RUN)
Не стоит ничего изобретать! Природа сама об этом давно позаботилась! Круговое движение двух полярных активностей Demand и Supply поддается тем же законам, что и суточное вращение Земли вокруг своей оси. Это своего рода 24-тактовый циферблат, проходящий четыре фазы движения: утро, день, вечер и ночь. Обратите внимание, насколько органично вписался сюда цикл PDCA!
От себя добавлю лишь небольшую интерпретацию. Термины Plan, Do, Check, Act – это точки, разделяющие фазы цикла. Фазы между точками имеют почти такой же смысл – «Планирую», «Делаю», «Проверяю» и… как ни странно, «Отдыхаю». Так уж распорядилась природа – три четверти активных и одна четверть пассивная.
Demand и Supply, продвигаясь вперед вдоль оси времени, вращаются вокруг нее, находясь в полной противофазе. Время на рис. 5 направлено вперед. В точности вдоль вашего взгляда на эту картинку. Перпендикулярно этому рисунку. Так что труба активностей напоминает скрученную двухцветную карамель из детства. Именно так, не растворяясь друг в друге, а закручиваясь в две спирали по оси времени, Demand и Supply взаимодействуют друг с другом.
Вы не можете одновременно все бегать по клиентам, а вернувшись от них, все вместе наваливаться на решение одной-единственной задачи. Каждый должен заниматься своим делом. Хотя в новых организациях, в стартапах, все поступают именно так, оправдываясь и называя себя гордым словом «команда».
Чтобы увидеть суть периодичности фаз Demand & Supply, предлагаю, подобно тому как конфетная обертка разворачивается в фантик, развернуть круговое вращение потока работ в одну ось координат (рис.6).
Рис. 6. Развертка трубы активностей
Посмотрим на медленный цикл глазами Demand. Все очень похоже на происходящее в реальном бизнесе. На первой фазе, пока вы изучаете рынок и планируете будущие проекты, технари-исполнители уже выполнили очередную прошлую задачу и проверяют результаты ее внедрения. Более сложен для реализации и понимания следующий второй этап. Технический персонал перешел в режим отдыха, расслабившись в поисках новой следующей задачи. А у вас наступила фаза 2 основной активности. Что же это за активность?
Результатом Demand не должен быть конечный продукт. Результатом Demand может быть только разработанные в терминах бизнеса архитектура и проект. На этой фазе вы можете оторвать Supply от заслуженного отдыха и привлечь его к разработке вашего собственного Demand-продукта, но ответственными за разработку документа, который часто называют БФТ (бизнес и функциональные требования), являетесь вы и только вы. Другого результата у Demand нет!
Именно поэтому в методологиях разработки программного обеспечения отдельно прорастают Business Use Cases и Software Use Cases, а в бизнесе отдельные два документа – БФТ и «Технический анализ и дизайн». Их просто делают разные группы людей, и это правильно.
На третьей фазе происходит своего рода квантовый переход и передача эстафетной палочки от Demand к Supply. В соответствии с технологией, Supply приступает к планированию изготовления продукта. В это же время Demand релаксирует, проверяя, наcколько качественно отработаны БФТ, и корректируя, пока еще не поздно, планы Supply.
На четвертой фазе Supply реализует план реализации продукта. Вмешаться в это исполнение со стороны Demand практически нет возможности. Это своего рода фаза отдыха Demand в ожидании реализации задуманного.
И так повторяется из цикла в цикл, от почти мгновенных автоматических операций Run с высокой тактовой частотой до медленных проектов Change, длящихся месяцами и кварталами.
Здесь хотелось бы точных научных или конкретных практических выводов. Думаю, что они лежат в самой модели и у каждого свои. Предлагаю лучше посмотреть и насладиться, насколько это гениально уже придумано до нас!
Маркетплейс Loginom
Прикладные решения, интеграции с популярными источниками данных и библиотеки готовых компонентов, расширяющие функциональность аналитической платформы Loginom
Решения
Трансформируйте свой бизнес с помощью прикладных решений на базе Loginom, чтобы быстро и эффективно решать ваши ежедневные задачи
Построение систем принятия решений
Loginom Decision Maker
Построение скоринговых моделей
Loginom Scorecard Modeler
Очистка и дедупликация данных
Loginom Data Quality
Интеграции
Упростите получение и передачу данных из популярных внешних сервисов и систем с помощью платформы Loginom
Сервис БКИ дает доступ к кредитным историям и отчетам, оценочным скоринговым рейтингам, маркерам мошенничества, проверкам движимого имущества в залоге и другим сведениям
Сервис БКИ предоставляет кредитные истории, информацию о платежном поведении и запросах в ЦККИ, скоринг-баллы, триггеры по заемщикам и т.д.
Сервис БКИ предоставляет кредитные истории физических лиц и юридических лиц, сведения о просроченных задолженностях, скоринг-баллы, сведения о судебных делах и другие данные
Библиотеки
Расширьте возможности аналитиков с помощью библиотек компонентов Loginom для автоматизации повседневных задач
Loginom Churn Kit
Компоненты с методами определения точек ухода клиентов, индекса оттока. Динамики удержания и оттока клиентов при контрактной и неконтрактной системах взаимоотношений
Loginom Silver Kit
Бесплатный набор компонентов, облегчающий рутинный труд аналитика по работе в Loginom
Loginom Vintages Kit
Компоненты для выбора окна наблюдения в кредитном скоринге на основе анализа вызревания портфеля просроченной задолженности
Главная
Увеличение ROI
Рост уровня сервиса
Контроль операционных расходов
Высвобождение оборотных средств
Ускорение потока
Быстрая реакция на спрос
Защита узких мест в цепи поставок
Рост скорости и надежности цепи поставок
Сила простоты
Быстрый процесс принятия решений
Сосредоточенность на отклонениях, а не на прогнозе
Demand Driven Material Requirements Planning (DDMRP) — это инновационная методика моделирования, планирования и управления цепями поставок для защиты и обеспечения потока материалов и информации.
Годами специалисты по управлению цепями поставок боролись с главным противоречием внутри системы — как соблюсти баланс между двумя важными показателями:
— оптимизацией уровней запасов
— повышением уровня сервиса
Конфликт в том, что чем выше мы хотим сделать уровень сервиса, тем больше запасов необходимо держать. Но чем больше мы храним запасов, тем больше оборотных средств у нас заморожено, а это ведет к снижению ROI.
Итого: в поисках мифического баланса команда отдела логистики напрасно тратит много усилий, то наращивая запасы для повышения уровня сервиса, то снижая уровни запасов для высвобождения финансов.
Задача DDMRP — оптимизация уровней запасов и повышение уровня сервиса одновременно, при этом методология позволяет снижать зависимость планирования производства от прогнозирования.
Деманд планирование что это
Набор аналитических компонентов на Loginom Demand Planning позволяет вывести на качественно новый уровень процесс управления запасами за счет автоматизации рутинных операций по подготовке данных и проведению сложных расчетов.
Благодаря автоматическому прогнозированию спроса у компании появляется возможность максимально обоснованно заглянуть в будущее, оценить вероятные потребности клиентов и запланировать под них закупки, распределение или производство продукции.
• Классификация номенклатуры по следующим характеристикам: динамика потребления/спроса, наличие компонентов временного ряда, тип сезонности, ABC и XYZ классификация и т. д.
• Выбор оптимальных методов прогнозирования в зависимости от полученных результатов
• Редактирование и сглаживание выбросов в истории продаж (с учетом промо активности, разовых крупных заказов, тендеров и иных событий)
• Восстановление упущенных продаж на основе спроса, истории остатков, ретро прогноза, форc-мажорных ситуаций и иных факторов, действующих в компании
• Прогнозирование спроса множеством прогнозных методов: многофакторные регрессии, методы экспоненциального сглаживания (Хольт-Винтерс, Тейл-, Кростон и другие), нейронные сети, ансамбли моделей и т. д.
• Выбор лучшей модели на основании ретро прогноза (тестовой выборки) и особенности динамики продаж каждого товара или услуги
• Планирование пополнения запасов с учетом целевого и страхового запаса
• Подбор и управление запасами на основании оптимальной модели управления в зависимости от характеристик товара
• Учет множества факторов — lead time, частота сбоев поставок, ошибка прогнозирования, качество работы поставщиков, целевой уровень запасов, кратность, окна поставок, время производства, доступность снабжения и т. д.
• Расчет плана перемещений и плана закупок
по всей складской сети
Подготовка данных
Классификация товаров или услуг
Прогнозирование спроса
Управление запасами
Визуализация
• Классификация номенклатуры
по следующим характеристикам: динамика потребления/спроса, наличие компонентов временного ряда, тип сезонности, ABC и XYZ классификация и т. д.
• Выбор оптимальных методов прогнозирования в зависимости
от полученных результатов
• Планирование пополнения запасов с учетом целевого и страхового запаса
• Подбор и управление запасами
на основании оптимальной модели управления в зависимости
от характеристик товара
• Учет множества факторов — lead time, частота сбоев поставок, ошибка прогнозирования, качество работы поставщиков, целевой уровень запасов, кратность, окна поставок, время производства, доступность снабжения и т.д.
• Расчет плана перемещений и плана закупок по всей складской сети
Infor SCM Demand Planning
Разработчики: | Infor |
Дата премьеры системы: | октябрь 2010 года |
Технологии: | SCM |
Infor SCM Demand Planning 6.4
Компания Infor объявила 4 октября 2010 года о релизе решения Infor SCM Demand Planning 6.4, входящего в пакет Infor Supply Chain Management, для использования специалистами по планированию спроса. Demand Planning 6.4 обеспечивает прозрачность спроса в нисходящем потоке производства и помогает предприятиям повысить точность прогнозов и учесть больший объем данных в процессе планирования спроса. Это позволяет им снизить затраты на инвестиции в материально-производственные запасы за счет более точных прогнозов потребительского спроса, что приведет к повышению уровня производительности, улучшению обслуживания клиентов и большему количеству возможностей для получения прибыли в условиях экономического спада.
Новые функциональные возможности помогают планировщикам лучше использовать данные по продажам и стимулированию сбыта в процессе прогнозирования, а поставщикам — в процессе обработки заказов, что приводит к разработке более точных и предсказуемых планов спроса и обеспечения поставок.
Расширенные статистические возможности в сочетании со знанием рынка, полученным на основе внешних и внутренних данных, обеспечивают максимальную точность планов спроса для единого международного подхода к «правильному положению вещей». Это позволяет компаниям удерживать материально-производственные запасы на минимальном уровне с меньшим моральным износом, что обеспечивает лучшее обслуживание клиентов в отношении наиболее прибыльных продуктов и, соответственно, повышение маржи.
Решение Demand Planning 6.4 можно развернуть на местах либо централизованно, чтобы управлять международным планом потребительского спроса и обеспечивать множество каналов вывода продукции на рынок.
Улучшенные возможности Demand Planning 6.4 включают в себя следующее: