Часть 3. Технические подробности
Общие предпосылки для устойчивого развития ERP-системы изложены в виде четырех условий выживания. Насчет 3-5% рынка ничего сказать нельзя определенного. Есть и другие факторы, кажущиеся малозначимыми, однако их удачное стечение может придать развитию такой системы сильный толчок. Исходя из эти общих условий попробую немного углубиться в технические детали проекта. Именно от деталей уже будет зависеть выполнение первых двух условий выживания из четырех перечисленных.
СУБД
В разных организациях уже могут существовать свои СУБД разных производителей (MS SQL Server, Oracle, DB2 и т.д.). Соответственно, уже есть в штате программисты, владеющими программированием на используемой СУБД. Поэтому, желательно, чтобы наша система умела работать с разными СУБД. У каждой СУБД есть свои особенности, которые, желательно, использовать, т.к. это позволяет зачастую либо значительно повысить производительность, либо сильно упростить решение задачи. Но, с другой стороны, хотелось бы иметь единообразный доступ к данным. Как это можно совместить? Есть два варианта: 1). стандартизировать набор хранимых процедур, образующих интерфейс работы приложения с СУБД (OpenDBI - открытый database interface); 2). использовать скриптовый язык и кодогенератор к нему, что позволит из единого скрипта под каждую СУБД генерировать свой SQL-скрипт для создания структуры БД, а для языка программирования- соответствующий набор классов для взаимодействия с СУБД. Для второго случая набор классов должен реализовывать некий единый интерфейс, чтобы гарантировать единообразную работу других частей приложения с БД. Мне нравятся современные фреймворки для работы СУБД типа hibernate. С их помощью можно успешно комбинировать описанные подходы: со стороны БД обеспечить некий стандартный набор хранимых процедур для работы с данными, а со стороны приложения- стандартный набор классов для работы с БД.
В разных организациях уже могут существовать свои СУБД разных производителей (MS SQL Server, Oracle, DB2 и т.д.). Соответственно, уже есть в штате программисты, владеющими программированием на используемой СУБД. Поэтому, желательно, чтобы наша система умела работать с разными СУБД. У каждой СУБД есть свои особенности, которые, желательно, использовать, т.к. это позволяет зачастую либо значительно повысить производительность, либо сильно упростить решение задачи. Но, с другой стороны, хотелось бы иметь единообразный доступ к данным. Как это можно совместить? Есть два варианта: 1). стандартизировать набор хранимых процедур, образующих интерфейс работы приложения с СУБД (OpenDBI - открытый database interface); 2). использовать скриптовый язык и кодогенератор к нему, что позволит из единого скрипта под каждую СУБД генерировать свой SQL-скрипт для создания структуры БД, а для языка программирования- соответствующий набор классов для взаимодействия с СУБД. Для второго случая набор классов должен реализовывать некий единый интерфейс, чтобы гарантировать единообразную работу других частей приложения с БД. Мне нравятся современные фреймворки для работы СУБД типа hibernate. С их помощью можно успешно комбинировать описанные подходы: со стороны БД обеспечить некий стандартный набор хранимых процедур для работы с данными, а со стороны приложения- стандартный набор классов для работы с БД.
Внутри стандартного набора хранимых процедур программист уже волен делать любые свои оптимизации. Это понравиться гикам.
Не забываем: обязательна поддержка региональных настроек и мультиязычности в OpenDBI!
Каждая подсистема (отдел кадров, ввод заказов и т.д.) такой ERP должна иметь свой OpenDBI (для разных подсистем можно использовать либо свои пространства имен, либо свои префиксы). Это позволит организовать обмен данными между подсистемами, написанными разными группами программистов. В перспективе, этот интерфейс может служить шлюзом для обмена данными между коммерческими ERP, которые обычно не сильно стремятся обеспечить свободную передачу данных с другими аналогичными продуктами- достаточно будет, чтобы в них появилась поддержка OpenDBI.
Ядро
Несмотря на то, что большую часть бизнес-логики можно реализовать внутри OpenDBI, на клиентской стороне останется немало функций:
Несмотря на то, что большую часть бизнес-логики можно реализовать внутри OpenDBI, на клиентской стороне останется немало функций:
- При изменении данных в одном окне надо, чтобы другие окна обновились. Значит нужен механизм рассылки сообщений. Более того, очень желательно, чтобы и другие клиенты могли по событию обновлять данные в интерфейсе пользователя.
- Нужна подсистема подготовки отчетов, чтобы пользователь мог сам разрабатывать отчетные формы, сохранять их (на диске или в БД), делать общедоступными и генерировать с их помощью отчеты.
- Подсистема для разработки форм ввода данных, сохранения (диск, БД) и предоставления общего доступа.
- Подсистема хранения пользовательских настроек.
- Подсистема тонкой настройки отображения данных под потребности предприятия или отдельных пользователей. Например, с помощью скриптов.
- Импорт/экспорт данных в другие форматы, например, MS Excel.
- Подсистемы взаимодействия с внешним ПО и оборудованием (например, сканеры штрих-кодов).
- Подсистема работы с региональными настройками.
- Подсистема поддержки мультиязычности.
Количество подсистем, естественно, не ограничивается этим списком. Важное требование к ним- модульная конструкция, позволяющая их гибко подключать или исключать из проекта. В качестве минимального требования к функционалу каждой подсистемы, они должны реализовывать некий стандартный интерфейс, позволяющий передавать/получать данные между подсистемами. Разные группы программистов могут реализовывать свои альтернативные подсистемы, например, может параллельно разрабатываться три подсистемы генерации отчетов. Но благодаря тому, что все три подсистемы будут реализовывать обязательно один и тот же интерфейс, то можно будет легко пересобрать ядро с любой из них. Каждая из них может предоставлять дополнительный функционал помимо реализации стандартного интерфейса.
Интерфейс пользователя
Так, как каждая из подсистем реализует некий стандартный интерфейс, то интерфейс пользователя можно реализовывать с помощью различных технологий. Например, собрать систему можно будет с пользовательским web-интерфейсом или сделать обычного "толстого клиента", а можно и то и другое одновременно.
Вывод
При таком подходе важно стандартизовать интерфейсы различных подсистем и OpenDBI. Это позволит при сборке собственной системы ERP задействовать подсистемы различных производителей и собрать систему под использование с требуемой СУБД. Небольшим производителям систем автоматизации выгодно использовать такую ERP, т.к. они смогут свои системы дополнить недостающими подсистемами или заменить свои менее функциональные подсистемы на аналоги. Вероятно, они (небольшие производители систем автоматизации) станут основными двигателями процесса разработки подобной ERP.
В конечном итоге, система получится очень гибкая, в ней возможно будет комбинировать подсистемы различных производителей, реализуя различный функционал. Таким образом, процесс внедрения будет аналогичен, тому как внедряются коммерческие ERP, с одной стороны. С другой стороны, сохраняется вся мощь универсальных языков программирования. Первые два условия будут соблюдены. А выполнение третьего условия (портфель внедрений) и четвертого (проверка временем) обеспечат те самые небольшие производители систем автоматизации. А насчет 3-5% рынка- уже время покажет.
В приведенном описании ясно прочитывается набор технологий, на базе которых можно реализовать подобную систему. Ясность того, как надо делать- это хорошо. Однако, с учетом того, что система должна быть рассчитана на использование в разных странах с разными стандартами документоведения, то даже простые модули в реализации будут сложны. Поэтому не испытывайте иллюзий по поводу того, что первую версию удастся выпустить очень быстро. Для практиков рекомендую внедрять уже готовые ERP системы, для пылких умов- присоединяйтесь к уже существующим проектам разработки ERP систем, например, OpenERP или выбирайте по списку, для авантюристов- дерзайте, конечно, но главное тут- сначала написать стандарты, описать интерфейсы, а уж потом программировать.
Это все: у меня эти мысли роились в голове, я их высказал.
