Комплексное решение для автоматизации бизнеса
Меню Закрыть
Главная Возможности платформы
Система позволяет настраивать бизнес-процессы без программирования. Это могут делать, например, аналитики после непродолжительного обучения, т.к. система оперирует понятиями, знакомыми любому из них: диаграмма классов, наследование, диаграмма состояний (Статусная модель — в терминах Метаплатформы).
Базовые понятия
Классы
Ключевым для Метаплатформы является понятие класса и механизм наследования классов. Создание классов и атрибутов — автоматически влечет за собой генерацию форми прочих системных сущностей для объектов этого класса.
Например, для того, чтобы получить форму с данными о физ. лице и форму со списком физлиц в системе, достаточно создать класс Физ. лицо с атрибутами, например, фамилия, имя и отчество. Если говорить о применения механизма наследования, то в приведенном выше примере можно легко получить формы с данными о пациентах. Достаточно создать класс Пациент — потомок Физ. лица. Для него даже нужно добавлять атрибуты ФИО, они наследуются от класса-родителя Физ. лицо.
Что такое BABOK@Guide, кому он и зачем он нужен: краткий обзор с комментариями
Статусная модель
Вторым фундаментальным понятием является статусная модель. Она представляет собой набор статусов, в которых может находиться объект класса и набор переходов между этими статусами. Например, для класса Пацент простейшая диаграмма статусов может быть следующей: Новый > Зарегистрирован. Эта диаграмма содержит 2 статуса и один переход из статуса Новый в статус Зарегистрирован.
В рамках каждого статуса могут быть определены следующие вещи:
- Доступность на редактирование всего объекта и/или связанных с ним объектов. Например, операция в статусе Завершена недоступна для редактирования, точно также как и связанная с ней коллекция мед. персонал, принимавший участие в операции.
- Правила валидации на переход в другие статусы, например, обязательность заполнения полей.
- Видимость полей и связанных коллекций объектов, например, в статусе “новая” для консультации скрыты коллекции назначений и диагнозов, пока она не перейдет в статус “начата”.
- Цвет объекта в таблице, например, включенные и отключенные услуги в прайслисте раскрашены в зеленый и красный цвета соответственно.
- Доступность операций печати, импорта данных и других. Например, для прикрепления пациентов по договору операция импорта пациентов из excel доступна только в статусе Импорт
Бизнес-функции (БФ)
Функции, выполняемые в системе. Функция состоит из произвольного набора шагов, выполняющихся последовательно. Шаги могут быть различных типов — например, отправить сообщение пользователю, сохранить значение в БД, открыть карточку объекта и так далее. БФ может быть вызвана несколькими способами, например, нажатием на кнопку в интерфейсе, или срабатыванием триггера.
На БФ лежит практически вся бизнес логика системы. Более подробно о типах шагов можно прочитать в соответствующем разделе.
Что такое БИЗНЕС АНАЛИЗ?
Имея представление о базовых понятиях, можно переходить к изучению основных возможностей Метаплатформы:
Источник: metaplatform.ru
Новый взгляд на традиционный подход к построению статусной модели
Аналитики, как правило, представляют статусную модель любого объекта в виде графа. В его вершинах находятся статусы, ребра показывают возможные переходы между статусами, а ориентация ребер показывает направление перехода.
1221 просмотров
Является ли такой подход универсальным и применимым в любой ситуации? Гарантирует ли он отсутствие необходимости вмешательства команды разработки в процесс движения объекта по статусам? К сожалению, есть ситуации, когда классическая модель не подходит. В этой статье расскажу о другом подходе к построению статусной модели и его особенностях.
Рассмотрим довольно широко распространенную ситуацию на рынке: вы разработали для заказчика (например, сети магазинов розничной торговли) мобильное приложение с возможностью оформления заказа на самовывоз. Но в скором времени планируется добавить возможность оформления заказа с доставкой на дом. У клиента нет собственной службы доставки, для оказания данной услуги будут привлекаться партнеры.
Для снижения тарифов на доставку и риска попадания в зависимость от конкретного партнера, клиент принял решение заключить договор сразу с несколькими курьерскими службами. Как итог: команде разработки необходимо реализовать несколько интеграций с системами курьерских служб.
После изучения процессов обработки заказов курьерскими службами заметим, что бизнес-процесс обработки заказа у каждого партнера имеет существенные отличия.
Как видно на рисунке выше:
- один партнер сам определяет список точек сети, из которых он сможет доставить заказ, а другой ожидает, что точка сети определяется магазином самостоятельно и передается в заявке на доставку;
- один партнер при получении заявки сразу приступает к поиску курьера, а другому партнеру для поиска курьера требуется дополнительное подтверждение заявки магазином;
- один партнер предусматривает возможность отмены заказа магазином после передачи заказа курьеру, а другой – нет.
Различия в бизнес-процессах, естественно, оказывают влияние на статусную модель заявки в системе курьерской службы. Поэтому у каждой курьерской службы статусная модель будет своя:
Первое решение, которое приходит в голову, это разработка статусной модели заказа в приложении индивидуально для каждого партнера по доставке. Очевидно, что такой подход довольно рискованный и вот почему:
- поддержка нескольких процессов обработки заказа будет существенно дороже, чем поддержка единого процесса для всех партнеров;
- риск ошибки кратно возрастает, так как каждый процесс подразумевает не только движение заказа по статусной модели, но и реализацию бизнес-логики внутри приложения;
- подключение нового партнера потребует существенных затрат по времени и финансам, так как необходимо будет реализовать еще одну полноценную интеграцию;
- курьерские службы тоже развивают свои ИТ-системы. Их статусная модель может со временем меняться, что приведет к необходимости изменения статусной модели в приложении.
А есть другие варианты?
Давайте попробуем абстрагироваться немного от нашей задачи и представим, что нет никакого приложения, все заказы принимает оператор по телефону. Доставляют заказы несколько курьеров-иностранцев, о ходе процесса доставки они сообщают с помощью коротких sms-сообщений на родном языке. Учет заказов и их актуальный статус оператор ведет на листке бумаги.
В зависимости от особенностей национальной культуры, личных качеств и темперамента оператор будет получать от курьеров совершенно разную информацию. Например:
- немец сообщит о получении заказа в точке сети и о его передаче клиенту, а в случае задержки всегда предупредит о причине и времени;
- итальянец дополнительно расскажет все, что произошло с ним по дороге, заодно поинтересуется, как дела у оператора;
- француз же не заметит опоздания, но обязательно в первом сообщении поздоровается и пожелает хорошего дня.
Первая проблема, которую нужно решить, это перевод текста sms-сообщений на русский язык. Чтобы не переводить каждое сообщение, создадим справочник, отображающий текст сообщения от курьера и его перевод на русский язык. При получении sms-сообщения оператор сверит его текст со справочником. Если перевод отсутствует, значит, курьер сообщил новую информацию.
Ее необходимо перевести и добавить в список сообщений. Для всех курьеров справочник должен быть единым, ведь совершенно не важно, кто из них сообщил о вручении заказа клиенту – немец или француз.
Поскольку часть sms-сообщений не будет иметь к заказу никакого отношения, если оператор будет фиксировать на листе учета заказов все полученные сообщения, он очень быстро запутается. Если позвонит клиент и спросит: “Где сейчас находится мой заказ?”, оператору придется пролистать переписку, чтобы найти сообщение, касающееся именно заказа. Поэтому необходимо фильтровать сообщения, которые курьеры присылают оператору.
А на листке учета заказов фиксировать только важную информацию.
Источник: vc.ru
Структурируй это: как в ДОМ.РФ выстроена работа над крупными проектами
Информационно и технически Единая информационная система жилищного строительства (ЕИСЖС) позволяет переводить отрасли жилищного строительства на проектное финансирование.
Каждый сервис внутри ЕИСЖС — это сложная информационная система с большим количеством интеграций, и поэтому увеличение количества разрабатываемых сервисов требует структурированного подхода к аналитике всех проектов.
Каждый аналитик нашей команды выступает в роли как бизнес-, так и системного аналитика и ведет в среднем по два проекта. В таких условиях проектные команды в целом и аналитики в частности должны быть высокоэффективны, легко переключаться с одного проекта на другой.
В этой статье мы расскажем, каким образом нам удается поддерживать баланс между высокой производственной нагрузкой и бережным отношением к сотрудникам.
Основа нашего подхода в части аналитики — шаблон спецификации требований, который разработан с учетом особенностей систем внутри ЕИСЖС и рабочих процессов при разработке программного обеспечения внутри ДОМ.РФ.
Спецификация требований программного обеспечения — структурированный набор требований к программному обеспечению и его внешним интерфейсам. Он нужен для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт.
В отличие от технического задания (как приложения к договору) или постановки — в виде описания в трекере задач, — спецификация описывает актуальные требования к системе с учетом всех ранее выполненных изменений. Система меняется, и вместе с ней меняется спецификация. По спецификации можно отследить как путь развития системы, так и актуальное состояние системы.
Пользователями спецификации являются почти все участники процесса:
- Бизнес-заказчик;
- Аналитик;
- Архитектор;
- Разработчик;
- Тестировщик;
- Технический писатель.
Вот, что дает нам единый подход, понятный и привычный всем участникам процесса развития ЕИСЖС:
- позволяет сократить время на погружение нового специалиста в проект, а также на переключение сотрудников ИТ-подразделения между проектами;
- снижает количество вопросов между участниками проектной команды, а значит — и затраты времени на каждый этап разработки. Разработчик всегда знает, где описаны требования, тестировщик не тратит время на поиск описания сценариев, а технический писатель может разработать полный комплект отчетной документации только на основе уже готовых постановок;
- облегчает восприятие IT-информации для сотрудников бизнес-подразделений, в интересах обеспечения деятельности которых разрабатываются сервисы;
- приводит к тому, что спецификация согласуется с заказчиком, поэтому записи спецификации являются зафиксированной договоренностью между исполнителем и заказчиком;
- позволяет определить, каковы были требования в любой момент времени за счет того, что спецификация поддерживает историчность изменения требования — на случай противоречий между любыми участниками процесса. Следовательно, если система работает, как описано в спецификации, то это не может считаться багом, и все новые требования должны стать доработкой.
В основе рассматриваемого шаблона лежит подход Boundary-Control-Entity, который лучше других подходит к разрабатываемым нами системам и проектам.
Его принцип — в декомпозиции требований на три слабосвязанных слоя: требования к данным, требования к функциям и требования к интерфейсу.
Помимо этих слоев в спецификацию могут быть добавлены дополнительные слои, которые не будут реализовываться, но нужны для лучшего понимания разрабатываемой системы.
Слои описываются отдельно, но между ними присутствуют связи. Такой подход позволяет минимизировать влияние изменений в одном слое на другой. Так, например, изменения в интерфейсе не должны оказывать существенного влияния на функции или данные.
Как оценить качество нашей спецификации?