В этой статье я расскажу про функциональные классы ERP-CRM систем, постараюсь описать, что же такое система ERP-Платформа, какую занимает нишу и как же правильно организовать структуру системы.



В статье я будут рассказывать только об облачных системах. Где пользователь зашел, зарегистрировался, и пользуется. Коробочные системы — отдельная тема.
Облачные системы популярны, доступны. С ними просто знакомиться, ежемесячные платежи небольшие.
Для некоторых компаний облако неприемлемо. Они хотят работать на своем оборудовании, в своей закрытой сети. Так спокойнее. Но знакомятся с системой перед покупкой опять же в облаке. Из облачной всегда можно сделать коробку, а вот из коробки облачную не всегда.

Различных облачных ERP-CRM систем много. Я бы все разделил на 4 типа:
1) Статичные
2) Статичные+
3) Полу динамичные
4) Динамичные



1) Статичные

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

Вариант это по сути простой и не замысловатый. Разработать такую систему можно быстро.
Но их уже практически не осталось, ибо прикрутив API такая система становится «Статичной+».

2) Статичные+.

Это развитие Cтатичной системы. Отличается тем, что разработчики прикрутили API. Т.е. пользователь может создать(или купить готовое) какое-то внешнее приложение. Это приложение умеет общаться с основной системой, получать или передавать в нее данные.
Но проблему индивидуализации бизнес-процессов это решает отчасти. По сути логика работы самой системы тут не меняется и пользователю все равно придется подстраиваться под систему. Система даже банально не позволит сделать отчет с совместным использованием данных системы и нескольких приложений (данные в разных местах), если она конечно вообще позволяет конфигурировать отчеты…

Такие системы популярные — т.к. они достаточно просты в создании, и если прикрутить сюда хороший маркетинг, нанять хороших дизайнеров, то все получится. Так же они могут вокруг себя собрать разработчиков внешних приложений, интеграторов и т.п. Т.е. дают хлеб еще куче народу, тем самым еще больше укрепляют свое положение на рынке.

Статичные системы хороши в каких-то узкопрофильных направлениях. Для другого профиля придется строить другую систему. Если Вы хотите обслуживать любые области, то статичная система — тупиковый путь развития. Статичные облачные системы «ERP» быть не могут, т.к. это требует глубокой индивидуализации бизнес-процессов клиентов, а это может дать только следующий класс: «Динамичные системы».

3,4) Динамичные (Полу динамичные)

Динамичные системы — умеют подстраиваться под пользователя.
Они имеют ядро-интерпретатор, который умеет выводить интерфейс пользователю согласно внутренним настройкам конфигурации. Когда пользователь открывает страницу, система считывает конфигурацию этой страницы и строит элементы в нужных местах.
Пользователь может самостоятельно править эту конфигурацию. Такие системы дают пользователям непревзойденную гибкость, подстраиваются под любой бизнес-процесс, и позволяют как раз построить «ERP» систему. Можно создать такую конфигурацию, которая будет охватывать жизнь предприятия.
Как правило такие системы имеют на своем борту встроенную систему программирования. Система программирования — апогей гибкости настроек. Если настройки программы все время развивать — в итоге Вы получите встроенную систему программирования.

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

Динамичность таких систем бывает разная.
Я выделяю тут несколько пунктов:
1) Конфигурация интерфейса
2) Конфигурация структуры базы данных
3) Конфигурация обработки данных

Если в системе реализованы не все пункты, то я ее отношу к классу «Полу диномичные». Я знаю системы, которые позволяют создавать таблицы и добавлять поля в БД, но не позволяют конфигурировать интерфейс.

1) Конфигурация интерфейса.
Под этим понимается, что:
А) можно свободно конфигурировать существующий интерфейс и создавать новый интерфейс к новому модулю.
Б) Интерфейс «двухмерный», а в некоторых случаях и «трехмерный», если есть наслоения вариантов. Т.е. можно управлять любой точкой страницы.

Есть системы класса Статические+, которые осознали таки свои проблемы и пытаются сделаться хоть в каком-то виде Динамичными, сделав добавление новых полей в списки. Но это не решит проблем. Управление интерфейсом сведено к одномерному списку. А технически это какая-нибудь универсальная таблица со ссылками что-откуда-куда и блобами, чтобы впихнуть любой тип поля.
Если система была изначально заложена как статика, какие костыли к ней не прибивай, выше головы не прыгнуть. А когда бизнес уже налажен — все убивать и с нуля делать новую систему — очень сложно.

2) Конфигурация структуры БД
Можно добавлять новые поля к таблицам, создавать новые таблицы, делать запросы в БД, производить модификацию данных.

3) Конфигурация обработки данных.
Может реализовываться:
А) Прослойка между получением данных из БД и выводом их на экран. Например на php, или каком-то своем придуманном языке.
Б) Обработка данных на уровне БД посредством PL\SQL и выдача интерфейсу уже готовых данных. Это более перспективно. Тут появляется возможность еще строить триггеры, т.к. это частный случай процедур. В первом варианте с этим будут проблемы.
Так же порог вхождения тут ниже, не надо обучать своему языку. SQL он и в Африке SQL, только интерфейсы разные.

Статья эта о системе "ERP-Платформа", которая имеет на своем борту все 3 пункта, и третий пункт по варианту Б. Обработка данных осуществляется на уровне БД. Есть полный цикл конфигурирования БД из веб интерфейса: таблицы, процедуры, триггеры.

Конфигурирование интерфейса

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

Каким же образом достигается такая гибкость в индивидуальном управлении системой?

Структура построения веб страницы:

Веб страница состоит из областей, называемых Закладками.

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

Приведу тут пример заявки. Сверху основная область (Закладка 1). Ниже список Закладок со своими функциями, по которым пользователь может переключаться. В примере открыта Закладка 3 «Планируемое».


Далее Закладка делится на ячейки. Как в экселе. Можно объединять ячейки между собой, например 3 столбца и 2 строки в одну ячейку. Здесь делается любая структура вывода информации на экран.

В каждую ячейку могут выводится различные структуры: просто текст, данные из БД, элемент ввода/редактирования данных, табличные структуры, ссылки и т.п.

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

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

Что такое внешние условия?
В свойствах ячейки или столбца/строки указывается процедура, которая при загрузке страницы выдаст номер экрана ячейки или условие для вывода столбца/строки. А уже в процедуре делается обработка данных и условий, и принимается решение на вывод того или иного. Иными словами, при загрузке страницы дергается процедура. которая выдает решение выводить элемент или нет.

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

Мобильная версия

Еще ячеистая структура очень удобна для автоматического преобразования в мобильной версии. Чтобы вывести страницу «компактно», достаточно все ячейки страницы просто расположить в один столбик. Например, если компания разработала какой-то свой модуль, ей не надо делать что-то специально для мобильной версии. Модуль в нее автоматически попадет. А ведь многие компании содержат целые подразделения, чтобы разработать-поддерживать мобильную версию. А тут все автоматом, без усилий.
Дополнительно есть функционал ручной корректировки для увеличения «красивости». Можно отметить например, какие ячейки выводить не надо, или как сократить текст в таблице в зависимости от формата мобильного вывода.

В итоге из вот такого:


Абсолютно автоматически получается вот такое:


Универсальные права доступа

Так же благодаря ячеистой структуре гибко реализуется система прав доступа.
Уровень доступа детализируется вплоть до каждого элемента страницы. Можно дать сотруднику доступ к странице, но ограничить к тем или иным элементам страницы, вплоть до отдельных ячеек и элементов редактирования.
Уровень доступа можно не указывать изначально, он задается по умолчанию в свойствах ячейки, но перекрываться если в Роли прав сотрудника прописано иное.
Так же права доступа наследуются: страница-закладка-ячейка, если иное не указывается в элементах.

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

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

Мультиязыковые возможности

Мультиязыковые возможности системы — еще один бонус ячеистой структуры. Ограничения по языкам нет. Пользователь сам может добавить любой язык и перевести на него элементы системы.
Каждый элемент меню, закладки, ячейки, элементы форм и т.п. могут быть переведены на любые языки.
Технически это делается просто, есть таблица в которой указано:
1) номер языка
2) тип элемента
3) номер элемента
4) текст элемента

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

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

Пример автоматического перевода текста ячейки


Пока есть некоторые проблемы с ивритом и арабским, т.к. там зеркалирование, но над этим работаем. Будет автоматически все.

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

Взаимосвязь интерфейса и БД

Интерфейс должен как-то общаться с БД. Вместе со ссылкой, на страницу передаются входные параметры, например номер Задачи. По входному параметру страница выводит в ячейки нужную информацию из БД. Так же стараница умеет производить модификацию данных в БД из форм, заполненных пользователем.
Для этого существуют структуры под названием «Источники данных». Это ссылки, в которых описывается, какую процедуру из БД дернуть, в какие поля процедуры вписать какие входные параметры, какие выходные параметры страница получит из процедуры и куда их направить.
Источники данных бывают «Глобальные» и «Локальные». Глобальные выполняются при загрузке страницы. Локальные выполняются по событиям, например при нажатии кнопки. Чтобы записать введенную пользователем информацию указывается кнопка, при при срабатывании которой, источник выполнится. В его входных параметрах указываются соответствующие поля, откуда возьмется информация.

Технически Источники данных — структура, позволяющая странице при загрузке сформировать на лету и выполнить соответствующий запрос в БД. А после правильно распорядиться полученной информацией.

Конфигурирование базы данных

В ERP-Платформе пользователю предоставляется полное управление своей БД. Пользователь управляет таблицами, процедурами и триггерами. Все из веб интерфейса своего аккаунта.

Создание таблиц и полей в принципе стандартно.
Единственное отличие от обычных БД, есть тип данных Image. Тип данных для хранения изображений.
Соответственно процедуры умеют тоже с ним работать. Умеют с изображениями работать и Источники данных веб страниц, а так же ячейки умеют их выводить, элементы форм — их загружать.

Процедуры поддерживают полноценный PL\SQL. Можно делать запросы, циклы, условия, строковые операции, операции модификации данных и т.д. Много встроенных системных функций.
Существуют и необычные структуры. Например, прямо в процедуру/триггер можно встраивать структуры API. Т.е. прямо из триггера в БД (по событию), передать информацию куда-то во вне. Пользователь структуру API сам настраивает, и сам настраивает адреса куда передавать.
Триггера создаются на события записи данных, модификации, удаления и любые их комбинации.
Можно встраивать процедуры в процедуры, любой вложенности.
Есть планировщик заданий, где можно ставить процедуры в плановый запуск по графику.

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

Например, можно в объявлении переменных, автоматически создавать их на основе данных выбранной таблицы, сразу с названием и нужным типом данных.
Можно автоматически заполнять ими into в select по соответствию имен. Так же можно в inset и update автоматом выставлять соответствия полей и переменных.

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

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

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

С выводом табличных структур можно тоже можно делать различные групповые операции над столбцами.

Естественно можно копировать структуры ячеек, шаблонов страниц, элементов форм и т.п. Можно делать даже снэпшоты процедур и откатываться если что не так.

Благодаря CRUD подходу разработка становится быстрой.

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

Конфигуратор отчетов

В ERP-Платформу встроен мощный конфигуратор отчетов. О нем недавно выходила хорошая статья.

Базовая конфигурация

Конечно же, если предоставить пользователю голое ядро системы, то будь она хоть тысячу раз крута, он просто не врубится что это такое и с чем это едят.
Суть в том, что на борту уже что-то должно быть. Причем желательно, чтобы это что-то было хорошо, красиво и удобно сделано, и подходило большинству компаний без доработок. Новый пользователь, приходя в систему, смотрит на красивость и функциональность внешнего вида, а не вдумывается в крутизну внутренних возможностей.
Так же желательно сделать «режим обучения», где новым пользователям будет выводится описание элементов, с объяснением что откуда и куда. Такой подход здорово помогает.

В ERP-Платформе это называется «Базовая конфигурация». Если она где-то не подошла, ее легко можно изменить под нужды клиента.
Конфигурацию можно развивать сколь угодно глубоко, делать любые сложнейшие интерфейсы и обработку данных.

Базовая конфигурация настроена под законченный цикл обслуживания клиента. CRM — для работ по привлечению новых клиентов, задачи-проекты для работ по предоставлению услуг клиентам, заявки для регистрации и решения проблем клиентов.

В текущий момент в базовую конфигурацию входят:
— Задачи и SCRUM доски к ним.
— Проекты
— Заявки (система Xelp Desk)
— CRM (лиды, предложения, сделки)
— Система ведения контрагентов
— Графики, объекты
— Система согласования счетов

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

В заключении хочу сказать, что очень приятно, когда на просьбу пользователя что-то изменить, можно ответить "Да, без проблем!" и тут же решить пользовательскую проблему, чем ответить "Для такой индивидуальной доработки Вам надо приобрести коробочную версию, а потом заплатить нам за доработку… денег и через… все будет готово".

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