Nick Malik пишет, что автоматизации бизнес-процессов мешает ориентированность языков их описания на человека, а не на машину.
Во-первых, мне кажется, что это не столько проблема языка, сколько проблема подхода тех, кто на этом языке пишет - язык в данном случае может помогать или мешать в тех или иных аспектах, но не самодостаточно определять этот подход. Как есть шутка про отдельных "технических программистов" о том, что "я на любом языке могу написать программу на Фортране", так и про некоторых аналитиков бизнес-процессов можно сказать, что у них на любом языке получается должностная инструкция. Хотя и сложно спорить с тем, что существующие языки сами по себе недостаточно совершенны - это показывает хотя бы то, что повсеместно до сих пор используются собственные неформализованные нотации (к примеру, вряд ли кому сейчас придёт в голову проектировать алгоритм на АЯРНе при наличии существующих ЯП - а с BP* такое случается сплошь и рядом).
Во-вторых, что важнее, если в самом реально существующем процессе имеется некоторый неявный участок, решение на котором может разниться в зависимости от предпочтения оператора, то такой процесс можно записывать хоть на ассемблере - всё равно изначально существующую неопределённость одним лишь использованием предельно чёткого средства описания не исправить. В процессе закрытой от внешних источников обработки количество информации может лишь уменьшаться, но никак не увеличиваться. Такие попытки напоминают сцены из кино, когда герою удаётся рассмотреть мелкие до невидимости детали на фотографии с использованием цифрового увеличения - с тем отличием, что происходят не в кино и имеют соответствующий финал.
Иными словами, автоматизация бизнес-процессов в том виде, в каком они существовали на предприятии до автоматизации, зачастую может действительно не иметь никакого смысла. Соответственно, ИТ-специалистам ради успеха дела нужно уметь обоснованно настаивать на предварительном изменении процессов, которые являются слишком "человечными" - что не слишком приятно, т.к. эти умения лежат уже вне области собственно ИТ.
Posts
10 comments:
Не знаю, кто такой Nick Malik, но он пишет полную чушь.
Дело не в том, КОМПЬЮТЕРНОЕ или ЧЕЛОВЕЧЕСКОЕ поведение моделирует язык. Дело в сложности алгоритмов и в сложности их формального описания и формальной верификации.
Язык не поможет от этого.
Ну, примерно это я и имею в виду.
Собственно, тут фишка в том, что некоторые процессы реально невозможно или очень тяжело описать не в силу их запутанности (это не принципиальная проблема), а в силу завязанности на человеческое решение. И доблесть айтишника здесь не в том, чтобы всё же пытаться эту систему замоделировать - всё равно не получится! - а в том, чтобы а) сказать честно, что у вас "всю систему надо менять" и б) не сказать это в случае, когда проблема как раз в запутанности, т.е. решаема.
Правильно. Надо не подгонять языки под менеджеров, а менять их самих на программы.
DSL.
Каждый правильный ойтишнек в определенный момент должен полностью зогбыть о том кто его ебет и кормит.
И сразу же пойти прогуляться по соответствующим ресурсам в поисках нового места работы.
2nekuts: я не совсем понял, это положительная характеристика или отрицательная.
Но с определённого уровня начинаются такие проблемы, куда деваться.
ну да, я потому и решил уходить из IT постепенно, что техническая сторона уже давно сведена к "интеграции решений", критическая масса софта и аппаратных мощностей была накоплена к концу 90-х
Отрицательная, Юр.
Есть достаточное количество областей, в которых полная формализация в принципе невозможна, а на изначальные причины такого положения вещей повлиять никак нельзя.
И, когда ойти начинает диктовать условия бизнесу...
Короче, ищем другое ойти, которое сможет дать соответствующий инструмент, а не возопит о "Человеческом. Слишком человеческом".
Разумеется, такие области есть. Но их надо либо не задаваться целью их непременно автоматизировать, либо действительно уходить.
Если начальство где-то услышало очередной buzzword и требует его воплощения, но при этом категорически не готово модифицировать процессы и инфраструктуру, то не исключён вариант, что итоговое решение будет смотреться как седло на корове.
В такой ситуации действительно лучше уйти.
Хотя, конечно, это всё не отменяет того, что перед тем как что-то модифицировать, надо семь раз отмерить и осознать, что именно, собственно, хочется от изменений выиграть. Речь о том, что такие ситуации, когда что-то приходится менять в консерватории, всё-таки бывают. Господствует же позиция, что таких ситуаций не бывает в принципе, бизнес идеален, а дело айтишника тупо обслужить то, что есть.
Post a Comment