Концепции построения ERP-систем на предприятии

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

Для чего вообще нужны концепции?

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

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

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