Комментарии 26
Из любопытства, Вы подсчитывали сколько ч/ч у вас заняла разработка, и сколько получилась в конечном варианте стоимость велосипеда?
Теги заданы только потому, что стек подразумевает их использование и в статье есть упоминание об этом. Сам код как Вы правильно заметили не публикуется.
Мало систем вы посмотрели. Есть же ещё DocVision или Directum. Они не имеют интерфейс a-la 1С, зато когда у вас встанет вопрос версионности утверждаесых документов или построентя ЮЗДО или взаимодействия с внешними коньрагентами, вам бы не пришлось мигрироватьь со своего «велосипеда». Это не считая того, что вкнжоры таких систем в этом процессе собаку съели. В общем, скорее, хобби за счёт конторы и по согласию рук-ва, безусловно.
Ваши комментарии более чем понятны. Это рассматривалось. И более того часть функциональности, которую Вы описали у нас есть. Но Вы не учли те моменты, которые я указал в требованиях. И не в последнюю очередь стоимость владения продуктом. Полагаю Вы знакомы с ценами озвученных Вами решений? И можете ли Вы утверждать, что их ценовая политика не изменится? Вендор готов по одному Вашему пожеланию вносить изменения под вас?
На счет хобби за счет конторы — это некорректное утверждение.
На счет хобби за счет конторы — это некорректное утверждение.
Прежде всего, хочу извиниться за кучу опечаток — мобильный клиент не поддерживает многострочное поле для ввода, ничего было не видно.
Я специально отметил, что по согласованию с рук-вом. Но любая непрофильная деятельность — это, чаще всего, невозвратные расходы. ТСО решения складывается из многих вещей. Кто поддерживает-развивает ваше решение? А через 5 лет? 10?
Да, знаком. Стоимость лицензии фиксированная (у них все же не подписка), стоимость поддержки разная у разных партнеров. Более того, вы можете подготовить своих специалистов _или_ найти готовых на рынке — т.к. решения распространённые.
Партнеры вендора могут кастомизировать под вас. При этом есть best practices, к-рым необязательно следовать, но стоит понимать, что они сложились не просто так.
На счет хобби за счет конторы — это некорректное утверждение.
Я специально отметил, что по согласованию с рук-вом. Но любая непрофильная деятельность — это, чаще всего, невозвратные расходы. ТСО решения складывается из многих вещей. Кто поддерживает-развивает ваше решение? А через 5 лет? 10?
Полагаю Вы знакомы с ценами озвученных Вами решений? И можете ли Вы утверждать, что их ценовая политика не изменится?
Да, знаком. Стоимость лицензии фиксированная (у них все же не подписка), стоимость поддержки разная у разных партнеров. Более того, вы можете подготовить своих специалистов _или_ найти готовых на рынке — т.к. решения распространённые.
Вендор готов по одному Вашему пожеланию вносить изменения под вас?
Партнеры вендора могут кастомизировать под вас. При этом есть best practices, к-рым необязательно следовать, но стоит понимать, что они сложились не просто так.
Я специально отметил, что по согласованию с рук-вом. Но любая непрофильная деятельность — это, чаще всего, невозвратные расходы. ТСО решения складывается из многих вещей.
Вы не поверите, но любая деятельность, которая не связана с профильной деятельностью компании можно считать невозвратными (по Вашей терминологии). Но как раз невозможность повлиять на затраты владения проприетарного решения — это в бОльшей степени невозвратные расходы. Более того, любые траты на ит, бухгалтерию, юридический отделы — невозвратные. Поэтому тут смысла не вижу это обсуждать.
Кто поддерживает-развивает ваше решение? А через 5 лет? 10?
Мы.
Да, знаком. Стоимость лицензии фиксированная (у них все же не подписка), стоимость поддержки разная у разных партнеров. Более того, вы можете подготовить своих специалистов _или_ найти готовых на рынке — т.к. решения распространённые.
Фиксированная — на текущий момент. И Вы действительно вчитывались в условия? За каждый отдельный модуль — плати. За поддержку через год — плати. За пользователей — плати. Поэтому через 5-10 лет данное решение станет золотым. И это при том, что далеко не все в данном решении удобно. Я общался с людьми, которые внедрили у себя «ТЕЗИС» (к примеру). Теперь согласование у сотрудников превратилось в «мУку».
Партнеры вендора могут кастомизировать под вас. При этом есть best practices, к-рым необязательно следовать, но стоит понимать, что они сложились не просто так.
Слово могут — здесь принципиально. За какие деньги и в какие сроки? Я знаю во что это в итоге выливается. Только одно «внедрение» будет вам стоить больше, чем заплатили изначально за продукт.
Это внутреннее решение, не претендующее на большее, надеюсь?
Интересно взглянуть на интерфейс конструктора воркфлоу. Это просто список\таблица узлов в определенном порядке или графический мини-редактор, где можно прорисовать дерево, а условия пропуска навешать по клику на узел? Сколько себя помню, дьявол в подобных архитектурах кроется в подсистеме администрирования бизнес-процесса. Она может быть настолько непрозрачной для конечного пользователя, что админом становиться сам разработчик, т.к. кроме него никто не может разобраться в хитросплетениях правил и переходов, ну или да — людям потом мучаться. Особенно когда кол-во узлов перевалит за десяток, а то и сотню. По вашей задаче, на вскидку — допустим у нас есть 3 участника: экономист, валютчик и главбух. Сценариий 1: если валюта рубль и сумма < 1000 000, заявка от инициатора попадает только к экономисту (конечная инстанция), если валюта НЕ руб. и сумма < 1000 000 в руб. эквиваленте, то только к валютчику (тоже конечная инстанция), а если сумма >= 1000 000 в руб. эквиваленте, то сразу к главбуху, минуя экономиста и валютчика. Сценарий 2: все тоже самое, только к главбуху на согласование заявка должна попасть после экономиста и валютчика в любом случае, конечная инстанция — всегда главбух. Т.е в обоих сценариях – это будет одна и та же прямая линия узлов, которые отличаются только условиями пропуска, в которых не дай бох ошибиться? И чтоб увидеть полную картину сценария, надо ковырнуть каждый узел на предмет условий пропуска? Ну такое. Когда их 2-3 еще может быть. Я бы скорее смотрел в сторону дерева с навешиванием условий перехода (а не пропуска) на ребра графа, а не на узлы. Визуально узел – это, например, прямоугольник с именем\должностью\ролью согласующего, от него линия на следующий «этаж» к ромбику\трапеции с условиями, и может даже с несколькими выходами по кол-ву условий на следующий «этаж» других согласующих с валидацией полноты и непротиворечивости этих условий и т.д. Еще на конструктор полей формы из админки интересно было бы глянуть, как он работает. И к какому событию прихардкодили нотификацию? Сейчас угадаю — при согласовании\отклонении заявки одним из участников или при её закрытии, об этом сразу оповещаются все участники цепочки, не? В любом случае спасибо, что поделились опытом.
Интересно взглянуть на интерфейс конструктора воркфлоу. Это просто список\таблица узлов в определенном порядке или графический мини-редактор, где можно прорисовать дерево, а условия пропуска навешать по клику на узел?
Таблица. Дерево (граф) мы
Т.е в обоих сценариях – это будет одна и та же прямая линия узлов, которые отличаются только условиями пропуска, в которых не дай бох ошибиться?
Да
И чтоб увидеть полную картину сценария, надо ковырнуть каждый узел на предмет условий пропуска?
Почти. Но не совсем. Для каждого узла у нас отображается, что для него могут отработать определенные условия пропуска.
Я бы скорее смотрел в сторону дерева с навешиванием условий перехода (а не пропуска) на ребра графа, а не на узлы
Спасибо за Ваш взгляд. Это действительно важно, так как Вы первый, кто на мой взгляд задаете конкретные вопросы с конструктивными предложениями и мыслями. Значит либо сталкивались с реальными аналогичными задачами, либо просто интересна сам тема?
Еще на конструктор полей формы из админки интересно было бы глянуть, как он работает.
Как доберусь до системы, сниму скрин.
И к какому событию прихардкодили нотификацию? Сейчас угадаю — при согласовании\отклонении заявки одним из участников или при её закрытии, об этом сразу оповещаются все участники цепочки, не?
Почти. У нас есть несколько событий на текущий момент:
- Изменение самой заявки
- Согласование/отклонение очередным согласантом
- Отзыв заявки или своего же согласования согласантом
Оповещения у нас действительно приходят тем, кто ранее успел согласовать заявку или на ком она находится в данный момент на согласовании.
либо сталкивались с реальными аналогичными задачами, либо просто интересна сам тема?И то, и другое. Архитектура типичная, еще наверное столкнусь с подобными. Мой интерес – это увидеть адекватный интерфейс редактора сценарев \ правил, в котором мог бы без бутылки разобраться и работать специалист соответствующей предметной области, а не человек из ИТ. Реальный кейс, чтоб раскрыть тему. Зашел как-то на проект, где сценарии описывались UML-подобной диаграммой состояний. Есть класс\объект — банковский счет, который м.б. в состояниях: активен, заморожен, арестован, закрыт и др — это узлы графа. Рёбра графа по переходу между состояниями соответствовали операциям и на них навешивались не только условия перехода, но и сопутствующие действия. Например, клиент (актор 1) пришел в банк и написал заявку на закрытие счета, операционист (актор 2) кликнул операцию закрытия на счёте в системе. Собственно ребро перехода счета из сост. активен в закрыт, так и называется “Операция закрытия счёта”. На ребре проверяется условие – если на счёте нулевой остаток, переход выполняется сразу. Если же остаток есть, из текущего сценария вызывается другой сценарий, где объект, который меняет состояние — это уже заявка на снятие клиентом оставшихся денег в кассе. Порожденная заявка может дальше менять состояния по своему сценарию, согласовываться кассиром (актор 3) с начальником отделения (актор 4) и т.д., а сам счет будет в это время находится в состоянии ”ожидает закрытия” и т.д. Это всего лишь эпизод из жизни счёта, а она у него бурная… К чему я? Вынести сценарии в админку, а не хардкодить — идея отличная, экономия трудозатрат по итогу должна быть серъезная. Но когда я открыл диаграмму в админке, то увидел нечитаемую картинку из наложенных друг на друга палок и говна. Растащить сотню состояний так, чтоб можно было сразу что-то понять оказалось нереально, при том, что граф местами может быть цикличный, например, если клиенту не выдали деньги в кассе, то из ожидания закрытия счет уходит обратно в состояние активный… Смысл в такой админке? Как сделать её для «самого тупого юзера»? Да, еще доводилось писать подобный мастер условий-правил перехода между состояниями, как у вас на скрине с условями пропуска согласанта. Но по ходу эксплуатации системы НЕ самым тупым юзером, вдруг выяснилось, что запись на 1С-подобном языке, типа
ЕСЛИ
Заявка.Остаток > 100 000 и Заявка.Вылюта = "рубль"
ТО
На_согласовнаие_к ("Занаида Павловна")
более удобоварима для восприятия, чем нагромождение элементов управления на форме. А если текст разукрасить, то вообще. Но возможно, есть смысл объеденить подходы – хочешь пользуйся мастером, а хочешь пиши скриптом – одно в другое должно автоматом конвертироваться. Но опять же, блин, идет уход от тупого юзера в ИТ. А я мечтаю полностью вылечить пациента, а не передавать его другим докторам… По поводу нотификации чуть позже еще мысль подкину, может пригодиться.
Как доберусь до системы, сниму скрин.Ок
А я мечтаю полностью вылечить пациента, а не передавать его другим докторам…
Мечта действительно хороша. К сожалению не всегда достижима. Иначе бы было уже решение, которе можно было использовать как «эталон». Мне пришлось поработать в прошлом над продуктом, где информация представляется всегда в виде графа. И что бы мы не пытались придумать, как только кол-во вершин переваливает за 20 с хитрыми переходами, уже сложно воспринимается на экране. А если за 100 — то вообще ничего не видно.
Это явно отдельная тема для обсуждения, и если будет желание, то можно в личке списаться.
Скрины скинул в личку
Даже в документообороте от 1С такое есть, пользователи сами процессы могут лепить, как в графическом виде, так и вручную с помощью мастера.
Это никак не противоречит тому, что я написал. При этом я не отрицал, что нет инструментов для визуального формирования графа. Если Вы почитаете выше, то вопрос не в том, что можно или нет предоставить возможность формировать граф переходов. А в том, что есть еще разные сущности, которые нужно уметь представить на этом графе так, что бы было понятно, да еще дать пользователю удобную возможность управлять этими сущностями.
И в комплексе, при определенном кол-ве ребер, вершин и дополнительных объектов (если вообще абстрагироваться от конкретного решения), которыми необходимо управлять, решение становится неудобным.
А если говорить про наш случай — если нам нужно будет, мы сделаем такой механизм, который будет удобен именно нам, исходя из наших потребностей и условий. Так как любая функциональность должна рассматриваться исходя их конкретных условий, и под копирку что то «предоставить» не получится.
И в комплексе, при определенном кол-ве ребер, вершин и дополнительных объектов (если вообще абстрагироваться от конкретного решения), которыми необходимо управлять, решение становится неудобным.
А если говорить про наш случай — если нам нужно будет, мы сделаем такой механизм, который будет удобен именно нам, исходя из наших потребностей и условий. Так как любая функциональность должна рассматриваться исходя их конкретных условий, и под копирку что то «предоставить» не получится.
Так я с вам и не спорил, ваше решение удовлетворяет требованиям бизнеса, и это хорошо. Но для любой другой компании оно будет малополезным.
У вас есть опыт внедрения аналогичных систем? Если да, то поделитесь пожалуйста этим опытом. Укажите, на какие моменты нужно обязательно обращать внимание, на какие не очень нужно. Что сейчас нужно заказчику или фирме, в которой производилось внедрение. Только не абстракные мысли, а пожалуйста из жизни.
Если отойти немного в сторону, то даже в jira есть замечательный инструмент для формирования бизнеспроцесса. Но сразу скажу, что обычный пользователь вряд ли сможет им воспользоваться. Все равно приходится его конфигурировать более-менее подкованному и понимающему специфику процесса, под который формируется бизнес-процесс (workflow) специалисту.
И тут вопрос стоит в том, что либо вам дают удобный инструмент, либо универсальный. И всегда приходится искать золотую середину (Наверное здесь есть специалисты, которые админят linux(unix) системы. Вот где гибкость. Но в командной строке и в конфигурационных файлах..).
Если отойти немного в сторону, то даже в jira есть замечательный инструмент для формирования бизнеспроцесса. Но сразу скажу, что обычный пользователь вряд ли сможет им воспользоваться. Все равно приходится его конфигурировать более-менее подкованному и понимающему специфику процесса, под который формируется бизнес-процесс (workflow) специалисту.
И тут вопрос стоит в том, что либо вам дают удобный инструмент, либо универсальный. И всегда приходится искать золотую середину (Наверное здесь есть специалисты, которые админят linux(unix) системы. Вот где гибкость. Но в командной строке и в конфигурационных файлах..).
Примеры конкретных задач:
1. Параллельное согласование договора несколькими исполнителями. Возможно несколько итераций.
2. Циклически повторяющиеся автоматически запускаемые задачи согласования.
3. «Бесшовная» интеграция с учётными системами.
1. Параллельное согласование договора несколькими исполнителями. Возможно несколько итераций.
2. Циклически повторяющиеся автоматически запускаемые задачи согласования.
3. «Бесшовная» интеграция с учётными системами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система согласования. Как мы велосипед изобретали