Концепции построения ERP-систем на предприятии (стр. 2 из 2)

Почему же очевидный на первый взгляд способ решать большую и сложную задачу по частям не гарантирует стабильной работы системы?

Чтобы ответить на этот вопрос, давайте рассмотрим предпочтительную и более современную аддитивную концепцию построения ERP систем.

Поставим задачу:

Необходимо, чтобы система "человек - компьютер" функционировала с минимальной энтропией.

Энтропия на уровне компьютера.

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

Энтропия на уровне человека.

Т.к. мы уже определили, что на уровне компьютера энтропия минимальна, то ответ однозначен - источником роста энтропии в системе является человек! Это он ошибается, не может быстро переключаться с одного дела на другое и плохо воспринимает более 9-ти объектов одновременно.

Как свести к минимуму человеческие ошибки (уменьшить энтропию системы)?

Во-первых, количество возможных решений должно быть максимально ограничено.

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

Во-вторых, совершенно необходимо, чтобы принимая решение человек имел ПОЛНУЮ и АБСОЛЮТНО ДОСТОВЕРНУЮ информацию, которая ему необходима (помните, в имитационной модели именно неполные информационные потоки между модулями разваливали систему) и в наиболее удобном для него виде. И только общее информационное пространство способно предоставить такие гарантии.

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

Итак, выпишем цепочку, при которой энтропия системы минимальна, а система, соответственно, наиболее стабильна и организованна.

Все просто: достоверная аналитическая информация - человек - правильное решение - корректное заведение данных по этому решению - хранение данных - аналитическая информация

Как видим, круг замкнулся и превратился в обозначенную ранее аддитивную концепцию.

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

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

Аддитивная концепция устойчива и эффективна при постоянно меняющихся внешних и внутренних условиях.

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

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

Какие наши действия?

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

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

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

В-четвертых, этапы должны относится к какому-либо документу (документ "заказ", этапы - сборка товара, его упаковка, отгрузка со склада, доставка до клиента; документ "счет" - этапы распечатан, отправлен и т.д.).

Далее, создаем таблицу видов этапов, таблицу в которой указывается, какой документ какие этапы содержит и таблицу, в которую заносим исполнение этапов при прохождении заказа. Естественно, все таблицы соответствующим образом связаны. Теперь система готова отследить движение каждого документа на каждом этапе его жизни, причем мы можем произвольным образом добавлять или удалять этапы, и если наши законодатели нас обяжут каждому клиенту выдавать по пирожку, то нам нужно будет лишь добавить в список видов этапов вид "пирожок", добавить его в этапы по заказу и контролировать процесс. Обратите внимание, не важно, какие именно этапы мы хотим отследить. Мы относимся к ним как к данным и просто храним их в нормализованном виде. В рамках аддитивной концепции совершенно простыми и красивыми действиями мы создали систему логистики, которая будет хорошо работать. В имитационной же модели нам пришлось бы создавать модуль логистики, настраивать обмен данными между остальными модулями и т.п., что отняло бы у нас кучу времени и стабильность системы осталась бы при этом весьма сомнительной.

Итак, в этой статье мы провели сравнение концепций построения ERP-систем. Автор намеренно не приводил конкретные примеры, читателю предлагается самостоятельно исследовать рынок корпоративных информационных бизнес-систем на предмет их принадлежности к той или иной концепции.