Графики работы сотрудников являются неотъемлемой частью любой CRM-системы.
Но в зависимости от специфики бизнеса клиента они могут быть самыми разными.
В поликлинике это график приема пациентов, в телекоммуникациях – график подключения клиентов, в школе – график занятий.
Все они различаются по структуре и сути.
У них разные заголовки, разные наборы полей, разные сетки.
Наша ERP-платформа ориентирована на быстрое развитие любой нишевой конфигурации, и мы задались вопросом, как можно все это сделать с удобством.
В первую очередь для себя.
Так что наши трудозатраты на разработку графика под конкретную нишу занимают не более человеко-часа.
До этого графика была чем-то вроде разработки на PHP. Но Боже! Чарльз! Каждый раз, когда вам нужен новый график для какого-то нишевого решения, вам нужно скопировать этот код и переработать его.
Индивидуальность графиков не позволяла централизованно изменить что-либо.
И вообще концепция нашей облачной платформы была подорвана тем, что клиент может настроить ее самостоятельно.
В результате мы сформировали следующие требования к графикам работы:
- Конфигурируемость
Их необходимо полностью настроить из веб-интерфейса.
- Переменный шаг
Они должны иметь переменный шаг сетки.
В одной клинике график приема врача может составлять 30 минут на одного пациента, в другой 20, в третьей час.
- Изготовленная на заказ шляпа
Графический заголовок может быть уникальным, т.е.
это может быть набор врачей, учреждений, преподавателей, бригад и т. д. В общем, все, что есть у клиента в системе.
Даже из того, чего мы не можем себе представить.
- Запись графа содержит произвольный набор полей
Набор полей можно указать произвольный, из любой информации, которая есть в системе.
И записи располагаются в соответствии с заголовком.
- CRUD
Записи графа должны быть CRUD (создавать, читать, обновлять, удалять), несмотря на произвольные наборы полей.
И не только это, но и использование процедур для организации сложных взаимодействий.
Пример: есть график работы по задачам.
Запись расписания показывает, кто это делает, где выполняется работа и т. д. + некоторые данные о задаче (например, ее номер и название).
Дополнительные данные записи расписания хранятся в одной таблице, а данные задачи — в другой.
При создании указывается номер задания, кто и где его выполняет. И данные будут отображаться из двух таблиц.
Редактировать можно только данные записи расписания, но не данные задачи.
Запись расписания должна быть удалена, но не задача.
Необходимо вести журналы того, кто и что делал с этой записью.
Поскольку его можно удалить и он не обязательно будет виден в графике, то до логов нужно как-то добраться.
Логичнее их вести в самой задаче, т.е.
при создании-изменении-удалении они должны записываться в отдельную таблицу и отображаться в задаче.
Такие вещи можно решить только с помощью хранимых процедур, так что можно решить как простые, так и сложные ситуации.
- Поля могут быть списками
Конечно, поля не должны быть только текстовыми.
Это также могут быть всплывающие списки из некоторых данных в системе.
- Поля могут быть ссылками
Удобно, когда, например, из графика работы задач можно перейти к самой задаче.
- Скрытие полей
Если в записи много полей, имеет смысл свернуть некоторые из них в категорию для удобства восприятия.
- Триггеры
Необходимо настроить реакцию системы на происходящее с записью.
Удобнее всего это сделать с помощью триггеров.
Например, если пользователю нужно записать какие-то логи действий на запись, или отправить уведомления сотрудникам, или даже отправить СМС клиенту, или вообще сделать что-то, что мы даже представить себе не можем.
- Перекрестные записи
Перекрестные записи — это записи из разных графиков, объединенные в один график.
Или появление записей в других диаграммах при появлении записей в текущей.
Например, бывают ситуации, когда одни и те же команды выполняют работу, например, и по запросам, и по задачам.
Те.
Им будет удобно иметь общее расписание, где будут отображаться задачи из разных расписаний.
Или вам нужен личный график сотрудника, с записями из всех графиков, в которых он участвует. Такие задачи немного сложнее типовых, но легко решаются с помощью триггеров и процедур получения данных.
Те.
по пункту 9 и пункту 5. а) на запись нужных графиков создается триггер, который создает запись в личном графике пользователя, если пользователь там присутствует (соответственно, если изменены - изменяются, если удалены - удаляются) б) в пользовательской диаграмме создаются дополнительные поля, которые будут включать необходимые данные, а также дорабатываются процедуры вывода записей, которые будут извлекать данные из таблиц других диаграмм по этим идентификаторам.
Подобные проблемы можно решить и обратным способом; при создании личного расписания сотрудника делается более хитрая процедура, которая будет отображать данные не только из личных таблиц, но и из таблиц других графиков, где сотрудник присутствует в данный день.
Возможны и подобные решения на основе этой конструкции.
- Наложения времени
Система должна корректно отображать пересечения записей во времени, а не, как большинство систем, где записи перекрывают друг друга и нет даже возможности читать нижние слои.
Вот так, грустно.
- Отчеты
Чтобы вы могли строить отчеты на основе данных графика.
Система хранения данных должна быть организована так, чтобы ее можно было подключить в конфигураторе отчетов.
Например, мне нужно было создать отчет, показывающий, какие сотрудники сколько времени тратят на поездки по задачам — вуаля! Заходим в конфигуратор отчетов, там выбираем таблицу, в которой хранятся данные из записей нужного графика и составляем отчет с помощью стандартного конфигуратора на основе данных из графика.
- Встраиваемость
График должен иметь возможность легко встраиваться в любое место на любой странице, т. е.
он должен быть стандартным элементом ввода, например текстовым полем или кнопкой.
К счастью, у нас был опыт разработки сложных стандартных элементов.
В частности, у нас есть стандартный элемент комментария, форма прикрепления файлов, форма связи и таблицы.
Все они добавляются в один клик как обычные элементы и без проблем настраиваются.
- Доступ и безопасность
Права доступа к карте в целом должны регулироваться общей системой прав, а внутри карты права доступа к записям должны регулироваться настройками карты.
Например, укажите, что только автор может редактировать свою публикацию, или свою группу, или отдел.
- Простота настройки
И конечно же, создание и настройка нового расписания должно происходить быстро и не вызывать никаких проблем.
В частности, у нас для типового случая (понятно, что есть, конечно, очень сложные) эта работа должна занимать не более человеко-часа.
На данный момент я не знаю систем с графиками подобной универсальности (если знаете, напишите в комментариях, интересно посмотреть) Общая схема настройки графа выглядит примерно так (не судите строго, я ее нарисовал сам).
Здесь необходим каждый элемент, ничего лишнего.
Вся работа начинается с понимания того, какой набор данных должен быть в записи и создания таблицы в базе данных для этого графа.
Например, для планирования работ над задачами в телекоммуникационной компании важно знать, когда будут выполняться работы, по какой задаче, для какого объекта и какая группа инженеров будет выполнять эту работу.
Поэтому мы создаем таблицу, содержащую всю эту информацию + служебные поля с идентификатором записи диаграммы.
(PS: наши таблицы можно редактировать прямо в облаке из браузера).
Это простой случай, но он может быть гораздо сложнее, когда полей или таблиц больше.
Всё, структура хранения сформирована и теперь графике нужно уметь с ней работать.
Каждую запись можно добавлять, отображать, изменять и удалять.
Т.
к.
набор данных и структура хранения могут быть произвольными, то эту структуру необходимо обрабатывать через хранимую процедуру.
Сначала вам нужно создать процедуры.
В нашем примере дело простое, и их можно создать в конфигураторе одной кнопкой с помощью функции «Создать стандартные процедуры».
Система самостоятельно создаст процедуры внесения, изменения, удаления и различные выводы с использованием этой таблицы.
Например, фрагмент автоматически созданной процедуры добавления выглядит так 
Все процедуры можно редактировать прямо из веб-интерфейса.
Логика композиции аналогична PL-SQL.
Если что-то сложное, то эти процедуры можно редактировать в зависимости от структуры хранения и задавать различные условия, циклы, выборки, обновления, вставки и т. д. В общем, рисовать любую структуру обработки.В расписании каждого действия указано, какая процедура отвечает за это действие.
Встроенные настройки графика
Но есть и «встроенные» настройки, которые можно только настроить, но не изменить структуру.
В этом просто нет необходимости.
— Координаты даты и времени являются неотъемлемым свойством любой записи.
— Расположение графика в системе.
Его можно редактировать с помощью встроенного редактора интерфейса и нет необходимости делать это с самого графика.
— Память о том, где находился пользователь — напрямую настраивать это свойство нет необходимости.
В настройках также можно задать Шаг (например, сетка 20 минут или 30) и Диапазон рабочих часов (например, от 8 до 20).
Временной диапазон нужен для того, чтобы отсечь лишнее, например, если все сотрудники работают по 8-часовому стандартному рабочему дню, то нет смысла отображать ночные часы.
Шаг – определяет сетку графика.
Например, в одной клинике график приема врача может составлять 20 минут, в другой — 15, в третьей — 30. Это все настраивается.
Однако это не означает, что запись нельзя вести вне сетки.
Вы можете вводить любые записи, но они будут отображаться в сетке.
Мы можем установить диапазон шагов на 5, 10, 15, 30, 60 минут. Выход записи Недостаточно создать и указать процедуру.
Планировщику необходимо понимать, как с этим работать со своей стороны.
Кепка
Самое главное – указать заголовок графика.
Какое из полей вывода процедуры должно быть заголовком.
Рассмотрим логику построения расписания занятий в образовательной организации.
Допустим, в записи есть набор «Группа учителей».
Здесь можно сделать шапку для Учителей, тогда расписание будет формироваться так: 
Или, может быть, по группам, тогда вот так: 
А можно вообще сделать 2 разных графика и отображать их так или иначе, пользователи сами выберут то, что им нравится.
Будут использоваться те же данные и те же процедуры.
Изменения в одном графике повлекут за собой изменения в другом.
Но в целом выбор зависит от вопросов целесообразности.
В заголовке должна быть фундаментальная, мало меняющаяся информация.
Если вы обслуживаете фиксированное количество объектов, то это должны быть они.
Если у вас фиксированное количество групп, то они есть.
С помощью шляпы можно делать очень интересные вещи.
Например, если вы укажете статус задачи в качестве заголовка, то при изменении статуса в задаче запись задачи на диаграмме перейдет в соответствующий статус.
Те.
на самом деле здесь можно почти создавать канбан-доски и т. д. вещи.
Когда мы связываем записанные данные посредством процедур с актуальной информацией в системе, они также могут ожить в виде графиков.
Очень гибкий механизм.
Также, если в процедуре указать условия фильтрации, можно сформировать данные заголовка в диаграмме с учетом произвольных фильтров.
Что не отображать Также вы можете указать, что отображать в записи, а что нет. Например, в процедуре в качестве результатов могут отображаться некоторые идентификаторы услуг для пакетов.
Информация, не значимая для пользователя, может быть проигнорирована при выводе.
Что скрывать Или можно вывести на экран, но сложить под кат. Информация не очень важная, но иногда необходимая.
Например, кто и когда создал эту запись, может понадобиться только в случае каких-то разборок, но не в оперативной работе.
Ссылки Еще очень удобно, когда какое-то поле может быть ссылкой.
Например, если мы составляем расписание задач, почему бы не нажать на ее номер, чтобы перейти к самой задаче.
У нас в конфигураторе есть стандартный механизм генерации ссылок.
Вы можете разместить их там и связать с полем на графике.
Все работает. Имя Конечно, поле должно как-то называться.
По умолчанию система возьмет имя из поля процедуры, но оно не всегда корректно для восприятия.
Поэтому иногда необходимо вводить альтернативные имена.
Например, для нас все вышеперечисленное выглядит так.
Флажки ставятся напротив полей указанной процедуры.
Вывод записи будет выглядеть так: 
Добавление новой записи
Поля для добавления новой записи должны быть определены процедурой добавления.
Информация должна быть предоставлена для каждого входного параметра процедуры.
Но есть хитрость.
Поля могут быть не только текстовыми, но и списками.
Возьмем наш пример для телекома, где есть задача, группа, объект. Мы не будем заставлять пользователя искать идентификаторы объектов и вводить их.
Необходимо наличие всплывающего списка с необходимой информацией.
Где я могу получить это? Для этого поле ввода процедуры должно подтянуть другую процедуру, которая выдаст, например, список текущих задач, или список необходимых объектов и т.п.
В этом случае нельзя просто указать поля таблицы.
потому что могут быть сложные фильтры.
В системе может уже быть 10 000 одинаковых задач, но вам нужно вывести список из 100, актуальных сейчас.
В общем процедура, которая дергается по полю другой процедуры.
На самом деле это звучит просто пугающе.
Эти вещи хорошо автоматизированы, процедуры по стандартным справочникам можно получить одной кнопкой.
Процедуры всевозможных списков групп, задач, запросов и т.п.
уже давно реализованы для работы всевозможных CRM-модулей.
Вам просто нужно их выбрать.
Если процедура с аналогичным функционалом уже существует, она копируется и далее редактируется.
Также необходимо указать, какое из добавленных полей будет заголовком.
Это нам понадобится в системе редактирования.
Для нас это выглядит так: 
Редактирование сообщения
Здесь все становится еще интереснее.
Недостаточно отобразить все поля списка, как в дополнении.
Вам необходимо выбрать текущие позиции в этих списках (выбрано).
Редактируем.
Для этого вам необходимо связать поля создания с полями вывода.
А в случае со списком полей не просто сбросить информацию с вывода, а точно знать идентификатор этой информации.
Те.
здесь вам нужно: а) указать порядок редактирования б) связать его поля с полями сложения в) связать свои поля с полями вывода данных записи, чтобы поместить текущие данные в списки Никаких других функций здесь указывать не нужно, потому что.
у нас уже настроены Вывод и Сложение.
При появлении окна редактирования система самостоятельно вызовет необходимую процедуру для каждого поля, получит данные, сравнит их с данными из вывода записи и поместит выбранное в списки, а текущие значения вставит в простые поля.
Наш выглядит так 
Удаление записи
Удаление самое простое.
Процедура удаления просто задается одним входным параметром: идентификатором записи графика.
Обработка событий при добавлении/изменении/удалении записей.
Триггеры.
Перекрестные записи.
Просто добавить/изменить записи в диаграммах недостаточно.
Нам все еще нужно управлять событиями.
Это открывает неограниченные возможности для настройки.
Управлять событиями на самом деле очень просто.
У нас уже есть таблицы, в которых хранятся данные записей диаграммы.
На этих таблицах можно разместить триггеры любой сложности.
Наш облачный конфигуратор упрощает эту задачу.
Например, нам нужны были журналы того, кто и что делал в записи.
Это просто.
Создается таблица для логов, а на таблицу графа помещаются триггеры, которые записывают данные модификации в таблицу с логами.
Также благодаря этому доступны перекрестные записи.
Например, когда в нашем примере задача назначена на группу, вы можете идентифицировать всех участников этой группы и поместить дубликат этой записи в их личные карты.
В этом случае добавление в персональные карты означает внесение записи в таблицу данных личной карты.
Он тоже является графом в этой системе, только настроен по-другому и отображается в другом месте.
Эта запись появится там.
Или вам нужно отправить уведомление пользователям группы.
Или отправить клиенту СМС, что к нему приедут для выполнения работы по такой-то задаче в это время.
Для этого просто создайте триггеры, которые делают записи в таблицах уведомлений или СМС.
Отчеты Отчеты на диаграммах тоже нужны, и при такой структуре их можно сделать.
Например, нужно было сделать отчет о том, как долго сотрудники были в командировках в предыдущем месяце.
Заходим в конфигуратор отчета, выбираем нужную таблицу, где хранятся записи диаграммы, задаем необходимые фильтры и функции агрегации — и вуаля, отчет готов.
Другие варианты использования графических данных Графические данные можно использовать где угодно при наличии развитого системного конфигуратора.
Например, в задачах мы легко смогли создать вкладку «Диаграммы» и с помощью одной простой процедуры отобразить информацию о том, как долго и кому предстоит выполнить данную задачу.
Наложения времени
Они случаются.
И нет ничего хуже, чем записи, набегающие друг на друга и мешающие прочитать нужную запись.
Эта проблема также решена.
Система автоматически размещает пересекающиеся записи рядом.
В данном случае используется только простой html, структура таблицы просто выстраивается необходимым для этого образом.
Система предусматривает уход на любую глубину, но более 2 записей – редкость.
Конечно, если время совпало, скорее всего, что-то было запланировано не так, как планировалось.
Человек не может находиться в двух местах одновременно, но даже такие ситуации необходимо отображать правильно.
Доступ и безопасность
Доступ разделен на 2 уровня.
Системная и Персональная графика.
Система определяется в основном редактором ролей и правами по умолчанию, указанными в конфигураторе интерфейса.
Например, если данной ячейке страницы (или унаследованным выше вкладкам, страницам, меню) запрещен доступ на чтение, то ни один пользователь не увидит этот график на уровне отображения интерфейса, пока этой области не будут назначены права чтения в Ролях пользователя.
Дальше идут внутренние права расписания.
Они могут быть 1) Редактирование - только автор — только авторская группа (все сотрудники, входящие в группы, в которых состоит автор поста) - только авторский отдел (все сотрудники, входящие в авторский отдел, по штату)
PS: наша рабочая группа и персонал могут отличаться.2) Удаление то же самое.Например, в одном отделе может быть несколько рабочих групп или в одной группе могут находиться сотрудники разных отделов.
Кроме того, один и тот же сотрудник может одновременно состоять в разных группах.
Система все это учитывает.
- только автор - только группа - только деление Зачем нужны внутренние права? Если это личная графика или есть какие-то особенности, то имеет смысл ставить только автора.
Но бывают сменные сотрудники и ситуации, когда запись нужно отредактировать, а сотрудника нет на работе.
Что делать? Такие графики имеет смысл редактировать группой или отделом, чтобы с этими записями могли работать другие сотрудники смены.
В расписании также можно указать Роль, имеющую право на администрирование.
Сотрудники с этой ролью будут иметь права как на редактирование, так и на удаление, независимо от групп и отделов.
У нас есть классная штука, которая значительно облегчает жизнь, если, конечно, вы умеете ею пользоваться.
Неопытному человеку может быть сложно в этом разобраться.
Но у нас составление такого графика в простом варианте занимает около человеко-часа.
Кроме того, мы также получаем глубочайшие возможности настройки и возможность взаимодействия с другими элементами системы.
Теги: #конфигуратор графиков работы #универсальные графики работы #ERP-системы #Программное обеспечение для службы поддержки #CRM-системы #Управление проектами
-
Время В Клеточном Автомате
19 Oct, 24 -
Ускоренный Курс Языков Ассемблера
19 Oct, 24 -
Свой Бизнес В Германии.
19 Oct, 24
