Тем не менее, в каком бы мире мы находились сейчас, имея десять лет назад таких заказчиков, как крупные банки и такого вендора с прорывными технологиями как ABBY?
Лет 10 назад обращался в ABBY чтобы с помощью продукта Compreno распарсить банковские регламенты с целью их Process Intelligence. Тогда вендор сказал что это неинтересно и на всякий случай задрал ценник, что даже для банковского проекта я бы не смог защитить. Пришлось пилить свои инструменты для анализа бизнес-процессов на коленке.
Тема «автоматический перевод «диаграмма-текст»», вынесенная в заголовок, не раскрыта.
Нет обоснование создания новой нотации.
Импортозамещение придумали политики, не разработчики, поэтому это не может являться продуктовой характеристикой.
Спасибо за пример. Но это же просто автоматизируется: если срок производства прошел на 80%, а прогресс производства меньше 80% — сформировать в СЭД претензию на производство. А при расчете KPI производства считать отношение претензий к заказам, и через пару таких циклов управления количество претензий должно снизиться.
Вы можете привести конретный пример, в каком случае работы не по регламенту (отклонения) возводятся в ранг ненормируемых и на них закрывают глаза? А то уже третий уровень комментариев, но дальше субъективных понятий типа просто и сложно не ушли.
-Раньше текст был захардкожен на уровне компонента
-Лицензионные ограничения заставляли нас пихать множество продуктов в один кластер
-Мы старались переиспользовать общий код внутри разных бизнесовых процессов, что создавало сложности с его модификацией.
В треугольнике Заказчик-ERP-Консультант, последние вряд ли являются самым слабым звеном. Мы научились достаточно точно оценивать достаточность компетенции и ресурсов консалтинга в проекте. А вот вероятность того, что Заказчик или ИТ-система подведут сложно спрогнозировать и риски ошибок больше.
Это если моделировать процесс, как поток работ: первый считает, второй и третий проверяют. Если смотреть на целевое назначение действий исполнителей, то это может быть «Сбор данных», «Согласование затрат» и «Ввод данных в учетную систему по факту отгрузки». Тогда эти работы нельзя ни по временной шкале совместить, ни по модели компетенций объеденить одному исполнителю, ни по ресурсам, рискам и т.п.
В вашем примере первый сотрудник отвечает за сбор данных, второй за коммерцию, третий за отражение операций в учетной системе. В какой момент вы приняли решение что процесс неоптимальный, по каким критериям?
Ну и к чему претензии? SAP не поставил вековые БП тяжмаша в коробке, или тяжмаш должен был из-за покупки лицензий изменить процессы сразу «как надо»? Или вообще не 6адо было ничего покупать, оставить как есть?
Соглашусь с комментатором выше, вы даже не попытались оцифровать процесс, сразу начали автоматизировать то, что есть, без трансформации бизнеса. Может конечному потребителю и не важно, сложная у вам навигация в приложении или нет, может ему важно не таскать брак обратно или бизнесу важно вообще не доводить до приёма рекламаций — и вот всего этого интересного, что входит в цифровую трансформацию в статье нет.
Пополнение топливного счета с привязанной банковской картой, чтобы этой же картой оплатить топливо — вообще не понятный сервис. А перевод с любых других карт (ФЛ или ЮЛ) кажется страшным сном бухгалтера.
Критерий в таблице покупателей хранить не надо. Можно сегментировать клиентов по этим критериям (и пересегментировать при необходимости). И в расчёте цены применять ценочувствительные сегменты клиента, а не его свойства.
Нет обоснование создания новой нотации.
Импортозамещение придумали политики, не разработчики, поэтому это не может являться продуктовой характеристикой.
-проще было архитектора заменить, а не движок.
От: MCHS
Пополнение топливного счета с привязанной банковской картой, чтобы этой же картой оплатить топливо — вообще не понятный сервис. А перевод с любых других карт (ФЛ или ЮЛ) кажется страшным сном бухгалтера.