|
Дальнейшее развитие рынка за счет поддержки проданного ранее софта является не столь благополучным, и уж точно не дает возможности развивать продукты в соответствии с быстро меняющейся средой и потребностями клиентов. Рынок стал быстро «схлопываться», что приведет в ближайшей перспективе к сужению количества вендоров до 3-4 основных, и небольшому числу второстепенных. В поисках новых «жертв» лидеры рынка обратили внимание на малоосвоенный, но потенциально огромный рынок бизнес-приложений для среднего бизнеса1. В относительно выигрышном положении оказались SAP и Microsoft, видимо спрогнозировавшие подобную ситуацию и пришедшие к ней с готовыми предложениями.
СРЕДНИЕ КОМПАНИИ В ЗЕРКАЛЕ РЫНКА БИЗНЕС-ПРИЛОЖЕНИЙ
Впрочем, цель статьи — не рассказать о вендорах, а предупредить возможные ошибки выбора приложений, которые могут дорого обойтись среднему бизнесу.
Для того, чтобы понять чего следует опасаться, рассмотрим типичные критерии выбора систем (см. табл. 1).
Таблица 1. Критерии выбора систем (в новом окне) >>
Несмотря на некоторые упрощения, таблица полностью корректна. Наиболее существенным упрощением является удаление из списка критериев реально второстепенных, но часто упоминаемых в рекламных проспектах и презентациях.
Что следует из таблицы? Прежде всего — потребности среднего бизнеса в области автоматизации существенно отличаются от «соседей», и, что наиболее существенно, на порядок сложнее, как соседей «сверху», так и «снизу». Если быть уж совсем политкорректным, то следует оговориться, что компетенции поставщиков во всех случаях являются очень важными и нелегко удовлетворить и крупный и мелкий рынки, но...
Сошлемся на мировую практику: верхний и нижний эшелоны заняты и почти полностью «окучены»2, причем немногими вендорами (не более трех-четырех), как для самого крупного, так и для малого сегментов. На среднем же рынке вендоров десятки (не у нас, конечно), а рынок по-прежнему достаточно «голоден» и динамичен.
В чем же проблемы среднего рынка?
Основная проблема — очень высокие требования к отраслевым компетенциям, что представляет крайнюю сложность для вендоров ПО. История разработки бизнес-приложений свидетельствует, что отраслевые компетенции в крупном и малом бизнесе были практически полностью оплачены деньгами покупателей. Денег хватило, так как в одном случае покупатели были весьма кредитоспособны (крупный бизнес), а во втором — покупателей было очень много, а интересы почти совпадали (см. требования в таблице для малого и микро-бизнеса).
В среднем бизнесе не так. Бизнес-требования и технологии многих компаний достаточно редки, уникальны или существенно отличны от типовых, применяемых «большими братьями». Однако, в отличие от последних, заплатить за разработку уникального ПО средний бизнес, как правило, не в состоянии. Указанный в таблице драматический разрыв в стоимости приложений для среднего бизнеса как раз и объясняется тем, что некоторым пришлось заплатить очень высокую цену за поддержку уникальных бизнес-процессов.
Признает ли вендор на стадии подготовки контракта свои неполные компетенции? Конечно же, нет! В лучшем случае вспомнит знаменитое правило 80/203. Это правило было выработано на рынке БП для крупных компаний, чтобы объяснить неполное соответствие функционала ПО требованиям заказчика. На этом рынке такая оценка действительно может быть работоспособна при корректной формулировке требований к ПО, но это неверно для среднего рынка. Компетенция же покупателя на начальном этапе выбора, как правило, недостаточна для корректной и полной формулировки требований, что приводит впоследствии к проблемам и существенному перерасходу средств.
Какие процессы наиболее сложны с точки зрения поддержки в бизнес-приложениях и требуют наибольшего внимания при выборе?
Основное — это планирование производственных процессов в интеграции с логистикой и финансами, то есть промфинтехпланирование в отечественной терминологии. Пример методологии, получившей широкую известность в этой области, — MRP II. Но повторим (в который раз), она применима только к очень узкому кругу технологий и бизнес-процессов (а ведь еще в советской практике 60-х годов была известна отраслевая специфика промфинтехпланирования).
MRP II также не поддерживает сложно организованную субконтрактную логистику поставок, получившую широкое распространение (особенно с появление т. н. 3PL и 4PL операторов). К сожалению, неприменима MRP II и к получившим в последнее время распространение методикам планирования по типу организации (заказного и полузаказного производства).
Совершенно не подходит MRP II к использующимся методикам организации «распределенного бизнеса», когда даже средняя фирма образует достаточно сложный холдинг и фактически отдает на аутсорсинг многие операции с целью оптимизации логистических и налоговых издержек. Последняя задача вообще очень сложна (и методологически, и с точки зрения поддержки ее ИТ), поэтому часто требует применения «полузаказного» программного обеспечения.
Вторая проблема, о которой также очень не любят говорить, — качество. Не бывает ПО без ошибок, причем чем оно сложнее, тем больше в нем ошибок. В малом бизнесе минимизация количества проблем достигается, как правило, за счет минимизации решаемых задач и колоссальной добровольной армии «бета-тестеров». В крупном — за счет полузаказной доработки, совмещенной с устранением ошибок (то есть «де факто» — за счет заказчика). Для среднего бизнеса первый путь невозможен из-за разнообразия решаемых задач, а второй — слишком дорог в большинстве случаев.
МЕТОДОЛОГИЧЕСКАЯ ОСНОВА ВЫБОРА БИЗНЕС-ПРИЛОЖЕНИЙ
Какие критерии можно использовать для выбора бизнес-приложений?
Прежде всего нужно смоделировать и описать функциональные потребности бизнеса, поддержка которых требуется от бизнес-приложений. Типичную сложность здесь представляет классификация всех процессов, выделение важных и второстепенных и расстановка приоритетов между функциями с точки зрения точности их поддержки.
Определенную положительную роль может сыграть референтная модель цепочек поставок. Обращение при выборе программных продуктов к теме оценки эффективности логистики продиктовано требованиями жесткой конкуренции, особенно в среднем и малом бизнесе. Компании вынуждены постоянно искать способы совершенствования своей деятельности в целом и его логистической составляющей, а следовательно, возрастает потребность в соответствующих инструментах.
Важным и своевременным оказалось создание стандартизированной модели логистических процессов (Supply Chain Operations Reference Model, SCOR). Она была разработана в 1996 г. как межотраслевой стандарт для управления цепями поставок4. Подготовкой модели занималась организация Supply Chain Council (SCC), которая насчитывает в настоящее время более 800 участников, работающих в различных отраслях (не только коммерческие фирмы, но и государственные организации, университеты и некоммерческие объединения). Целью является разработка и техническое описание стандартных моделей процессов (SCOR) и организация обмена информацией между предприятиями, входящими в SCC.
В официальном описании модели отмечается, что SCOR фокусируется на материальных и информационных потоках, не затрагивая при этом напрямую такие направления деятельности предприятия, как торгово-административную сферу, разработку дизайна продукции, справочную службу — информационное обслуживание потребителей (см. табл. 2).
Таблица 2. Область применения SCOR (в новом окне) >>
Как видим, SCOR не пытается описать все бизнес-процессы и виды деятельности предприятия, что видимо и невозможно. Однако видно, что модель охватывает практически все ключевые процессы, принципиальные для выбора программного продукта ERP-класса для среднего бизнеса5. Модель охватывает все процессы, которые подходят под определение стандартизуемых и по которым разворачивается самая острая конкуренция по эффективности и точности реализации. Не включенные в модель процессы, как правило, уникальны (совершенно или существенно), и с точки зрения ПО не входят в сферу компетенции типичных бизнес-приложений «класса ERP».
СТРУКТУРА И ПРИНЦИПЫ SCOR-МОДЕЛИ
Модель построена по блочному принципу. Используя составляющие ее структуру блоки, модель может описать цепочку поставок любой сложности и любой отрасли в одних и тех же терминах, с использованием единого общего набора определений. SCOR-модель может не только описывать, но и определять возможности изменений как для глобальных, так и для локальных цепей поставок.
Согласно концепции, поддерживаемой SCC, модель содержит семь основных разделов: иницирование, планирование, снабжение, производство, распределение, возврат, каталог терминов и определений (словарь), содержащий все стандартные определения, термины и метрики, использующиеся в SCOR-модели.
Интегрированная в SCOR-модель цепочка поставок охватывает все цепочки создания (добавочной) стоимости, т. е. все материальные, товарные и информационные потоки от поставщика поставщиков до изготовления и выдачи клиенту клиента.
Основные процессы
В основе SCOR-модели лежат пять основных логистических процессов: планирование, снабжение, изготовление, доставка/распределение и возврат.
Необходимо обратить внимание на то, что в модели подчеркивается исключительная важность планирования для управления бизнесом, что является относительно новым фактором в концепциях бизнес-моделирования (прежние практически всегда рассматривали планирование как обслуживающий процесс).
Планирование. Любая цепь поставок является интегрированной совокупностью процессов снабжения, производства и распределения, пересечение любых двух из них образует своего рода «связку» в цепи поставок. Эти процессы перемещают или преобразуют материалы и/или продукцию, причем каждый процесс является «потребителем» предыдущего и «поставщиком» последующего. Процессы планирования управляют функционированием этих «связок», позволяя сбалансировать всю цепь поставок, а каждая «связка» для успешного функционирования требует наличия процесса планирования. В виду этого процессам планирования придается особое значение.
К планированию в контексте SCOR относят все подготовительные виды деятельности по процессу, определение ресурсов, объединение требований служб снабжения, производство и размещение, планирование использования мощностей вплоть до окончательного распределения заказов. Планирование относится как к управлению спросом и предложением, так и к управлению инфраструктурой.
Компании, использующие SCOR, должны оценить ресурсы снабжения, обобщить и проранжировать потребительский спрос, спланировать наличие запасов, учитывать потребности дистрибьюции, наличие производственных мощностей, потребности в сырье и материалах для всех продуктовых групп и каналов.
Управление инфраструктурой включает формализацию и принятие ряда управленческих решений (покупать/производить), конфигурирование цепи поставок, долгосрочное планирование потребности в мощностях и ресурсах, бизнес-планирование, изменение ассортимента, расширение производства, управление продукцией с истекающим сроком годности, управление продуктовой линейкой.
Снабжение. Процессы снабжения определяют, прежде всего, приобретение, получение, проверку и предоставление поступающих материалов. Снабжение включает закупку материалов и продукции и поддержку соответствующей инфраструктуры, требуя эффективного управления процессами получения, приемки, проверки, содержания (хранения) и отпуска товарно-материальных ценностей.
Поддержка инфраструктуры снабжения включает: заключение контрактов с поставщиками, их сертификацию и поддержание отношений с ними, мониторинг качества снабжения, транспортировку от поставщиков, отслеживание оплаты их счетов.
Производство. К данному типу относятся все производственные процессы, начиная с требований на сырье и его получение, непосредственно само производство продукции, вплоть до монтажа и упаковки. Управление производственной инфраструктурой включает проектирование инженерных изменений, оборудования, управление статусом продукции и ее качеством, составление производственного графика и определение краткосрочной потребности в производственных мощностях.
Доставка/распределение. Содержит в себе определение спроса, управление заказами и процесс сбыта, включая управление складами и транспортом. Процесс доставки (распределения) состоит из трех компонентов: управление заказами, управление складированием, управление транспортировкой и установкой/монтажом продукции.
Управление инфраструктурой распределения включает определение правил распределения в канале и оформления заказов, управление качеством доставки.
Возврат. Сюда входит управление всеми возвратными потоками: возвратом дефектной продукции/товарных излишков, возвратом сырья/материалов поставщику, реверсивную логистику.
SCOR интегрирует пять указанных процессов с точки зрения системного подхода к управлению цепями поставок. Важно отметить, что при этом рассматривается расширенная цепочка поставок от сырья до конечного потребителя, даже если эти процессы и затрагивают «третьи фирмы», а не только «прямо связанные» элементы логистического процесса, принадлежащие одному юридическому лицу.
Организационно-функцональное наполнение
Помимо выделения пяти основных элементов, организационно образующих структуру модели, все процессы можно разделить по их организационно-функциональному наполнению на три типа.
Процессы планирования призваны согласовывать ожидаемый спрос с наличными ресурсами системы (потоки на входе и выходе) и распределять агрегированный спрос по всему горизонту планирования. Процессы этого типа обычно имеют регулярный характер, возникают через определенные интервалы, и влияют в первую очередь на такой показатель эффективности, как время реакции цепи поставок.
Операционные процессы (к ним относятся снабжение, производство, доставка, возврат) «запускаются» спросом (планируемым или реальным), который изменяет статус продукции. Они включают составление графиков и установление последовательности выполнения, обработку материалов, перемещение продукции.
Поддерживающие процессы подготавливают, поддерживают и управляют информационными потоками (и организационными отношениями), на основе которых и выполняются первые два типа процессов.
Следует обратить внимание, что SCOR фиксирует внимание как на процессах локального планирования транзакций6 (в данном случае речь идет именно о них), так и на информационной поддержке процессов, что практически явно указывает на связь процессов с поддерживающими их бизнес-приложениями. Подчеркнем еще раз, что SCOR-модель фокусируется на процессах, то есть на типе деятельности, а не на конкретном исполнителе/организационном элементе, в чем состоит принципиальное отличие от классических моделей моделирования и декомпозиции процессов.
Детализация процессов
Структура SCOR-модели содержит четыре уровня детализации процессов (см. рисунок).
Рисунок. Уровни детализации процессов (в новом окне) >>
На первом уровне (типов процессов) дается описание пяти ключевых процессов «в целом», здесь же компания устанавливает общие стратегические цели своей деятельности и готовит информацию для построения внутренней модели логистических процессов. На этом этапе компания определяет свои бизнес-цели и стратегию в отношении планирования, выбора источников поставок, производства и распределения продукции. Обычно на этом уровне и заканчивается выбор ПО для крупного бизнеса, если функциональные задачи выбора соответствуют приведенным в табл. 1.
На втором уровне (конфигураций — в терминологии SCOR) пять типов процессов разбиваются на категории, и компания может «сконфигурировать» цепочку поставок в соответствии с требованиями стратегии, учетом используемых технологий и т. д. На этом уровне каждый процесс может быть описан по типу/категории процесса. Категории процессов второго уровня представляют собой, по сути, различные варианты реализации цепочки поставок для каждого из пяти процессов. Категории процессов отражают отличительные особенности каждой конкретной цепи поставок в отношении того, как в ней происходит планирование, снабжение, производство, доставка и возврат продукции.
На данном этапе возникает уникальная конфигурация цепи поставок, учитывающая активы, объем и ассортимент продукции, требования технологии и другие особенности конкретной компании. Этот этап желательно всегда использовать при выборе ПО бизнес-приложений, в том числе и для крупных компаний.
На третьем уровне категории процессов разбиваются на элементы, их составляющие. Именно комбинация этих элементов будет определять конкурентоспособность компании на выбранных ею рынках.
Здесь даются дефиниции элементов процессов и их взаимосвязь, приводится информация на «входе» и «выходе» каждого элемента, перечислены параметры и меры, которые нужно использовать при оценке их эффективности. Там, где возможно, должны быть описаны лучшие методы ведения бизнеса и даны рекомендации по использованию ПО для их внедрения.
Таким образом, категории процессов на третьем уровне конфигурируются с помощью элементов процессов с учетом отраслевых стандартных рекомендаций.
Это последний уровень, на котором проводится моделирование с помощью SCOR-моделей. Поэтому предлагается использовать методы моделирования логистических процессов, таких, как модель цепочки процессов. Модель требует проводить дефиницию процессов в цепочке поставок на оперативном уровне в виде ограниченных частных процессов и задокументировать как временную и логическую последовательность производственных циклов выполнения заказов, так и оперативные базисные показатели.
В таком виде наглядные процессы представляют собой основу для выбора программных продуктов и создают возможность для первичного анализа таких факторов как время издержки и необходимые ресурсы. Для крупных компаний данный этап может оказаться слишком сложным и трудоемким, ввиду чего «де-факто» он содержательно осуществляется редко, а вот для среднего бизнеса он совершенно необходим, так как ошибка на данном этапе приведет к колоссальным издержкам из-за несоответствия функциональности программного обеспечения процессам предприятия.
На четвертом уровне декомпозиции при построении модели разбивают элементы процессов на составляющие их работы и элементарные операции, приспосабливая модель к особенностям ведения своего бизнеса. Набор работ и операций будет уникальным для каждой организации, поэтому, естественно, никакая общая модель не в состоянии их описать.
Собственно, на этом уровне и возникает ситуация «неудовлетворенности» заказчика стандартным ПО и появляется необходимость кастомизации продуктов под процессы конечного пользователя. К сожалению, это может оказаться очень непросто, и вместо изменения программного обеспечения под требования пользователя начинают кастомизировать процессы под то, что может поддержать ПО.
ЗАКЛЮЧЕНИЕ
В статье сделана попытка предупредить ошибки выбора бизнес-приложений для среднего бизнеса, которые могут повлечь за собой существенные финансовые потери и утрату ключевых элементов конкурентоспособности (что возможно даже более критично). Описанная SCOR-модель предоставляет компании возможность сбалансированной оценки и описания задач, связанных с внедрением бизнес-приложений.
Отметим, что совершенно необходимо участие высшего руководства предприятия в процессе расстановки приоритетов деятельности и поддержки этих приоритетов ИТ, определении потребностей бизнеса в ПО, обеспечении внедрения с целью достижения стратегической конкурентоспособности и скорейшей отдачи на инвестиции. Естественно, часто требуется, чтобы показатели эффективности (в том числе результаты внедрения ERP) были привязаны к финансовым результатам деятельности компании, что требует рассмотрения проекта внедрения как инвестпроекта с конкретным целями и задачами.
Об авторе:
Колесников Сергей Николаевич — независимый эксперт.
1 Согласно стандартной терминологии, к рынку SMB (small and medium business) относятся компании с годовым оборотом от 10 до 300 миллионов долларов. Ясно, что в странах СНГ верхний предел этого интервала скорее отвечает понятию "крупный бизнес".
2 Применительно к рынку малого бизнеса это означает, что несмотря на активную динамику компаний на данном рынке, "барьеры входа" на рынок очень высоки и выбор ПО осуществляется практически всегда из немногих известных игроков.
3 "Любое ПО удовлетворяет 80% потребностей покупателя, а 20% функциональности являются предметом доработки и кастомизации".
4 Название цепь, цепочки поставок не является вполне устоявшимся, поэтому в тексте будут употребляться оба варианта. Автору кажется более удачным название "логистическая цепочка".
5 Естественно, сфера применения модели может охватывать и выбор бизнес-приложений по функциональному признаку для любых по размеру бизнесов.
6 Термин "транзакция" в западной практике бизнеса понимается очень широко, в частности, любая финансовая или логистическая операции являются транзакциями, то есть представляют собой фиксированную последовательность действий, начинающуюся как раз с планирования.
|
