|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
Ситуация: Имеем большое предприятие с несколькими направлениями бизнеса. На предприятии стоит КИС собственного написания, в которой разросшемуся предприятию становится тесно и, которая не может дать всех разрезов отчетности, т.е. сделать бизнес прозрачным. Дорабатывать и перерабатывать смысла уже не имеет, надо писать заново. В работе предприятия наблюдаем давно устоявшийся, сложившийся годами бардак. По этому руководство имеет непреодолимое желание сменить КИС, чтобы получить эффективность деятельности как на ладони и готово полностью реорганизовать предприятие для наведения порядка и для (допускается) внедрения какой-либо готовой ERP. Естественно на этом фоне появляется консалтинговая группа, которая берет на себя описать бизнес-процессы, оптимизировать работу и помочь во всем в чем только можно. Команда бравых ребят - черный низ, белый верх, серьезный послужной список, уверенная и поставленная речь и прочая пыль в глаза. За достаточное время работы ребята испачкали кучу бумаги. Схемы БП (ARIS), методы оптимизации, отчеты, презентации – деятельность кипит, результатов на A0 валом. Все красивенько, красненьким, зелененьким, стрелочки…, сладкие речи о светлом будущем и т.п. Я понимаю, что подход, наверное, правильный. Это должно было случиться и должен быть в компании отдел, который в идеале знает все тонкости предприятия, может скоординировать работу подразделений, поставить задачу для ИТ, который в одной голове охватывает все бизнес-процессы и использует эту информацию. Это аналитик, точнее, как я понимаю, его идеализированный портрет. Что я наблюдаю: пыль в глаза и прочая мишура. Работа на уровне активистов комсомольской организации. Для ИТ эти схемы не несут никакой информационной нагрузки, т.к. диаграмма «действие -> результат» не говорит ничего, для ИТ интересно то что между. Я не понимаю как эту лабуду можно использовать хотя бы основанием для тех задания. А если внедрять чужую ERP будет сторонняя компания, интересно что они на это скажут. Подход к оптимизации бизнеса у них основан на выявлении и устранении проблемных участков процесса. Т.е. о реорганизации в целом говорить не приходится – тоже фигня. Разбираться в этом становится очень сложно из-за огромного количества «воды». Так кому оно нужно? Вопрос состоит в том, как выделить из этого рациональное зерно и взрастить его. Как должно выглядеть моделирование бизнес-процессов? Как оно используется на практике? Насколько оно оправдывает себя? Насколько оправдывает себя именно ARIS ? ЗЫ Книжки читал – тоже одна раздутая вода. В инете пишут в основном люди, зарабатывающие этим деньги. Интересны реальные проекты с реальными результатами, мнения заказчиков. Ну и консультантов тоже выслушаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 16:05 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
может быть не в тему но... по-моему, пространство для воды появляется тогда, когда нет четко определенных целей. когда человек не знает, что он хочет получить в результате той или иной кампании, о какой результативности можно вести речь? поэтому первым делом нужно задуматься, а ЧЕГО именно Вы ждете от тех бравых ребят. описать бп? предложить Вашей компании план реорганизации? если, как Вы говорите, у Вас нет собственных специалистов, которые могли бы перевести то, что наработали "бравые ребята" в практику, значит, нужно давать соответствующее задание ребятам или искать других людей. а на практике "пачкание бумаги" в итоге должно выливаться в конкретные официальные внутрифирменные документы и регламенты, должностные инструкции персонала, которому все диаграммы до лампы. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 17:42 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
Меня всегда приводят в уныние схеы бизнес-процессов, схемы БД, которые появляются еще до того как становится ясно зачем создается системы, кто ей будет пользоваться и как ею будут пользоваться. Конечно, как и сказал предыдущий оратор надо начинать с целей. Затем - то, что набило уже оскомину, но часто не выполняется - use case, варианты использования, прецеденты - как хотите. Пару лет назад некие головотяпы пыталичь врулить систему (я должен был внедрять) - в вколачивании данных участововали почти все работники большого производственного объединения - от кладовщиков - до высших должностных лиц. (И будет Вам "все в компьютере"). Когда я попробовал найти хоть одно подобие отчета, запроса - чего угодно - оказалось, что разработчик пока это не предусмотрел - Вы пока вколачивайте данные и растите до использования системы - а мы там уж пару SELECT-ов Вам напрограммируем. Самое интересное, что разработчики - по своей недолекости - в качестве конечной цели поставили автоматизацию поанирования и диспетчирования (типа MES), даже не подозревая, что имеют перед собой NP-полную задачу, и даже наметили срок внедрения (что-то там +0.5 года). Это, разумеется, анектодтический случай. Но use case нужны всегда и всем. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 18:31 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
apapacy аналогично полно анекдотичных случаев... когда начинается ввод реальной информации, то начинается корежиться схема данных, все сделанные предварительно отчеты идут в корзину. Так что анекдот Вы рассказали не очень смешной. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 18:54 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
Относительно КИС: Цель получить тех задание или хотя бы основание для него. Выделить основные модули системы, структурировать их взаимодействие, иметь детальное описание их функций, входящей информации, исходящих документов, отчетности. Как можно использовать схему БП ARISa для разработки? Может у нас схема неправильная? Но что дает разработчику например: Поступил заказ от клиента -> Необходимость внесения заказа в базу -> Заказ в базу внесен -> Необходимость обработки заказа -> Заказ обработан.... (документ "Заказ", исполнитель такой-то, с помощью "вот этого", на выходе "обработанный заказ") ? Что такое заказ? Какая информация должна вноситься? Что значит обработан? Какие алгоритмы расчетов? и многое другое не ясно. Это должно быть описано? Насколько детально? Ибо существующая макулатура мне как разработчику до лампочки. И интересно что на это скажут сторонние внедренцы ERP, в каком виде они захотят это видеть? Относительно структуры бизнеса: ist-stylish а на практике "пачкание бумаги" в итоге должно выливаться в конкретные официальные внутрифирменные документы и регламенты, должностные инструкции персонала и всё? Впрочем здесь более понятно - можно проводить стоимостной анализ каких либо блоков, их оптимизацию и реорганизацию. Что еще? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 19:33 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73 Как должно выглядеть моделирование бизнес-процессов? a1*x1+a2*x2+...+an*xn -> min x1+...+ <= b1 ... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 19:54 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73Относительно КИС: Цель получить тех задание или хотя бы основание для него. Выделить основные модули системы, структурировать их взаимодействие, иметь детальное описание их функций, входящей информации, исходящих документов, отчетности. Как можно использовать схему БП ARISa для разработки? Может у нас схема неправильная? Но что дает разработчику например: Поступил заказ от клиента -> Необходимость внесения заказа в базу -> Заказ в базу внесен -> Необходимость обработки заказа -> Заказ обработан.... (документ "Заказ", исполнитель такой-то, с помощью "вот этого", на выходе "обработанный заказ") ? Что такое заказ? Какая информация должна вноситься? Что значит обработан? Какие алгоритмы расчетов? и многое другое не ясно. Это должно быть описано? Насколько детально? Ибо существующая макулатура мне как разработчику до лампочки. И интересно что на это скажут сторонние внедренцы ERP, в каком виде они захотят это видеть? это ВАША цель - получить техзадание на разработку кис? а цели Вашей конторы? разработать и внедрить новую кис? что-то совсем непонятно, Вы пытаетесь что-то для себя выудить из того, что наделали ребята? а их обязанности как прописаны в договоре? они не должны Вам ставить техзадание? или должны, но в виде схем aris? если последнее, то видимо Вам таки придется повышать квалификацию и учиться применять aris на практике...а это литература, всякие там курсы-семинары... что на это скажут сторонние внедренцы, надо у них спрашивать, думаю, там тоже не везде одинаковые правила... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2008, 20:03 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73<...>Вопрос состоит в том, как выделить из этого рациональное зерно и взрастить его. Как должно выглядеть моделирование бизнес-процессов? Как оно используется на практике? Насколько оно оправдывает себя? Насколько оправдывает себя именно ARIS ?<...> ARIS как методология и совокупность нотаций - IMHO вполне оправдывает. ARIS как инструмент - очень дорогой. Впрочем, VAD, eEPC, и Organizational Chart можно и в OpenOffice Draw рисовать - не так удобно, конечно, и единый репозиторий со "словарями" объектов организовывать хлопотно, и многопользовательскую работу - тоже. Reports, ABC, BSC и Simulation - дело другое: разработчики ARIS не зря получают свою з/п. Процесс - последовательность функций. На определённом уровне детализации у для функции можно выделить конкретного исполнителя (персону, роль, должность), входы и выходы. Требуйте "спуска" бизнес-аналитиков до этого уровня :) . С точки зрения IT интересны те "as to be" функции, которые имеют информационные входы и выходы. На их основании можно написать варианты использования системы - и это "правильный" подход. Но в принципе, варианты использования уже видны в функциях и их последовательностях, так что для упрощения и экономии времени можно прямо на eEPC "прикинуть" подсистемы, экраны и информационные сущности будущей КИС, с которыми будет работать исполнитель функции. Это "неправильный" подход, т.к. требования смешиваются с архитектурой, но результат может быть вполне удовлетворительным. На всякий случай - в ARIS есть UML 1.1 и ERD, но IMHO в спец. средствах (том же PowerDesigner) они реализованы значительно лучше. А когда со стороны прийдут другие люди, внедрять свою ИС, скорее всего они постараются начать с изменения БП под свою систему, чтобы поменьше приспосабливать ИС к БП. И потребность в описании БП с большой вероятностью постараются свести к "та-а-а-ак, вместо этого БП должен быть вот этот, стандартный для нашей системы, вместо этого БП - вот этот, а вот тот БП вам совсем не нужен, т.к. наша система такого не поддерживает, и не возражайте, нам виднее!" ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2008, 01:05 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
"Не понятно" и "Не правильно" это разные вещи. Просто сам был свидетелем, когда пытались без описаний, на основании отдела со "знаниями всего предприятия" подсчитать прибыль :)) и смех и грех у них "это правильно" считается количественный учет ОС. Или (как обычно и совсем очевидно) договоры всегда ходили по одному кругу согласования, а схемами доказали (конечно разбирающимся в них) что на предприятии необходимо 2 круга Хотя... каждому своё ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 07:38 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73Я понимаю, что подход, наверное, правильный. Нет, не правильный. Правильный подход д.б. таким (очень грубо): 1. Формулируется цель создания КИС (вернее АСУП) 2. Цель декомпозируется на иерархию подцелей 3 Из целей формулируются задачи, решаемые АСУП 4 Разрабатываются технологические процессы решения задач (т.н. БП) 5 Разрабатывается собсно система ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 09:34 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73Вопрос состоит в том, как выделить из этого рациональное зерно и взрастить его. Попробуйте начать с должностных инструкций и регламентов (а если они есть то с их переработки) Как правило такой подход не требует привлечения аналитика со стороны, малозатратен и понятен руководству, однако в ряде случаев достаточно психологически сложен. Также не нужно в этом процессе опускаться "до уборщицы" Требования к документам: 1) не должны быть "формальными", а должны закреплять по шагам "сложившийся годами бардак". 2) должны быть формализованы отделом IT, разрабатываться только совместно с должностными лицами к деятельности которых эти документы относятся. 3) составлены исключительно в терминах участниках бизнес-процессов Цель такой работы: 1) получение данных о сложившей ситуации в целом 2) вовлечение пользователей лиц в процесс формирования требований к КИС 3) выявление "дыр", "неявных процессов" - в процессе создания должностных инструкций каждый будет стремиться взять на себя минимум ответственности, показывая максимум своей незаменимости Был опыт, когда в результате проведения такого процесса удавалось 1) обходится без "команды бравых ребят" 2) максимально детализовать требования для "команды бравых ребят" 3) провести "тендер" команд. ______________________________________________________ Ох ! Болят мои крылья ... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 12:36 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73Ситуация: Имеем большое предприятие с несколькими направлениями бизнеса. На предприятии стоит КИС собственного написания, в которой разросшемуся предприятию становится тесно и, которая не может дать всех разрезов отчетности, т.е. сделать бизнес прозрачным. Дорабатывать и перерабатывать смысла уже не имеет, надо писать заново. Помимо этих двух вариантов - перерабатывать или писать заново - есть третий: наладить управление бизнес-процессами "поверх" существующих систем. Это концепция BPM+SOA: первое - специализированный софт, предназначенный для управления бизнес-процессами, второе - архитектура интеграции процессов с существующими системами. Концепция эта сегодня становится очень популярна, принята всеми крупными ИТ-вендорами, поэтому заслуживает как минимум изучения до того, как вы сделаете вывод о том, что надо писать систему заново. iq_73Естественно на этом фоне появляется консалтинговая группа, которая берет на себя описать бизнес-процессы, оптимизировать работу и помочь во всем в чем только можно. Команда бравых ребят - черный низ, белый верх, серьезный послужной список, уверенная и поставленная речь и прочая пыль в глаза. За достаточное время работы ребята испачкали кучу бумаги. Схемы БП (ARIS), методы оптимизации, отчеты, презентации – деятельность кипит, результатов на A0 валом. Все красивенько, красненьким, зелененьким, стрелочки…, сладкие речи о светлом будущем и т.п. Вы описали метод работы 90-х годов. Сегодня BPM вытесняет традиционный реинжиниринг, который вы описали. Принципиальное отличие в подходе BPM: пользу приносит только исполняемый бизнес-процесс. Моделирование как таковое, без замкнутого цикла моделирование - исполнение - анализ и без непрерывного, итерационного усовершенствования, ничего не дает. "Нарисованная" схема бизнес-процесса перестает отражать действительность раньше, чем "бравые ребята" заканчивают "пачкать бумагу". Сходите на bpms.ru , если до сих пор не были. iq_73Я понимаю, что подход, наверное, правильный. Это должно было случиться и должен быть в компании отдел, который в идеале знает все тонкости предприятия, может скоординировать работу подразделений, поставить задачу для ИТ, который в одной голове охватывает все бизнес-процессы и использует эту информацию. Это аналитик, точнее, как я понимаю, его идеализированный портрет. Да есть, такой подход: аналитики сидят в одной комнате, ИТ-шники - в другой. Время от времени аналитики, нарисовав очередную схему очередного бизнес-процесса, "перебрасывают его через стену" программистами со словами "автоматизируйте". Но это абсолютно не то, к чему следует стремиться. BPM-система позволяет добиться совместной работы, при которой аналитики сами доводят бизнес-процесс до сначала ручного исполнения, а затем с помощью программистов связывают шаги процесса с автоматизированными системами. iq_73Что я наблюдаю: пыль в глаза и прочая мишура. Работа на уровне активистов комсомольской организации. Для ИТ эти схемы не несут никакой информационной нагрузки, т.к. диаграмма «действие -> результат» не говорит ничего, для ИТ интересно то что между. Я не понимаю как эту лабуду можно использовать хотя бы основанием для тех задания. Принятые в BPM workflow-диаграммы (в нотации BPMN или близких с ней) в этом отношении гораздо лучше IDEF или eEPC. iq_73Вопрос состоит в том, как выделить из этого рациональное зерно и взрастить его. Как должно выглядеть моделирование бизнес-процессов? Как оно используется на практике? Насколько оно оправдывает себя? Насколько оправдывает себя именно ARIS ? ЗЫ Книжки читал – тоже одна раздутая вода. В инете пишут в основном люди, зарабатывающие этим деньги. Интересны реальные проекты с реальными результатами, мнения заказчиков. Ну и консультантов тоже выслушаю. Прежде всего совет - забудьте о моделировании, озаботьтесь замкнутым циклом управления бизнес-процессом. ARIS, к сожалению, к этому приспособлен плохо, см. статью про roundtrip и топик ARIS vs. BPM . ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 13:07 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
2 iq_73 Пока что в ответах преобладает подход - "до основания, а затем..." Что вполне понятно - так привыкли, так работали много лет. Но всегда ли это оправдано - и с точки зрения средств, и с точки зрения целей. Итак, на предприятии есть КИС. Худо-бедно, но свои функции на определенных участках она выполняет (могу предположить, что это бухучет и возможно что-то еще). Если сносить старую систему и внедрять новую, то: во-первых, это недешевое удовольствие, во-вторых - это минимум 2 года нервотрепки, в-третьих, нет гарантии, что вы внедрите ту функциональность, которой ожидает руководство. Кроме того, как было сказано выше, при внедрении ERP вам будет предложено использовать те бизнес-процессы, которые уже описаны в системе. Любая, даже навороченная ERP-система дает возможность исполнять только те бизнес-процессы, которые охватывает ее функционал. То есть говорить об уникальных процессах, о покрытии "белых пятен" там, где функциональность "не попала в ERP" не приходится. Вполне вероятно, что вы просто получите порцию разочарования, а ваше руководство поставит крест на всех ИТ-инициативах. По поводу "белых воротничков". Эти люди выполняют именно ту работу, за которую им платят - они честно говорят, как нужно правильно жить. И слова при этом произносят правильные, и бумаг умных напечатают много. Очень много. Но от красивых бумажек толку никакого. Они устаревают быстрее, чем их успевают прочесть. А уж до реального исполнения... а они и не предназначены для исполнения. Они нужны для отчетности - вот она, работа. Выполнена. Ваше предприятие мы изучили и проблемы ваши тут и тут. А дальше - решайте. Для этой цели ARIS вполне подходит. Инструмент для ИЗОБРАЖЕНИЯ процессов. Что на деле? Реально результат можно получить только в том случае, когда созданная модель процесса может быть сразу исполнена. Когда шаги процесса остаются не на бумаге, а раздаются исполнителям в виде заданий в электронном виде. Для этого существует специальный класс программного обеспечения - BPM-системы. BPM-система (или BPMS) - это системная надстройка над существующими программными приложениями, которая служит одновременно и средством моделирования процессов, и средством исполнения процессов и средством интеграции. Благодаря этим возможностям BPMS часто отпадает необходимость избавления от старых приложений. Функционал старой системы может быть задействован в бизнес-процессах, исполняемых BPM-системой. Кроме того, добавление новой функциональности к старой системе или новой системы вполне адекватно воспринимается BPMS. Наиболее прогрессивный способ организации информационного пространства внутри предприятия - это SOA (сервис-ориентированная архитектура) под управлением BPM-системы. Кстати, возвращаясь к ERP. Еще каких-то 10 лет назад казалось, что поставь ERP - и будет тебе счастье. Но после выяснилось, что для счастья хотелось бы еще и CRM, и MES, и ECM и иже с ними. И никто не гарантирован от появления еще чего-то более совершенного. Меняется не только софт, но и платформы. И что? Каждый раз все с нуля? Не реально. Просто необходимо научиться использовать то, что уже есть, чтобы была возможность развиваться дальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 13:23 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
Спасибо, перевариваю... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 14:25 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73Ситуация: В теории я согласен с тем, что написал данный автор: AlexTheRaven На практике проходил подобный подход 3 раза :( Сделал следующие выводы: Попытка увеличить уровень детализации приведет к еще большему количеству "воды". Выделить из того, что получится рациональное зерно невозможно. Можно: Выбрать "критичный" (по меркам этих консультантов и вашему) процесс (не менее 4 шагов) и заставить их расписать его полностью (до уровня форм пользователей). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 15:01 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
andbary Можно: Выбрать "критичный" (по меркам этих консультантов и вашему) процесс (не менее 4 шагов) и заставить их расписать его полностью (до уровня форм пользователей). +1 Для того чтобы проверить качество яичницы, необязательно уметь нести яйца (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 16:08 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
Petro123 andbary Можно: Выбрать "критичный" (по меркам этих консультантов и вашему) процесс (не менее 4 шагов) и заставить их расписать его полностью (до уровня форм пользователей). +1 Для того чтобы проверить качество яичницы, необязательно уметь нести яйца (с) + еще 1, с небольшим дополнением: "расписывать" на на бумаге и не в visio, а в BPM-системе. Заставить не только расписать, но и пройти (т.е. исполнить при помощи автоматически сгенерированных веб-форм) от начала и до конца - тогда в результате получится нечто жизнеспособное. Полностью согласен с тем, что лучше разбираться с одним критичным, чем распылять усилия на "все" процессы. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 16:28 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
автор+ еще 1, с небольшим дополнением: "расписывать" на на бумаге и не в visio, а в BPM-системе. Заставить не только расписать, но и пройти (т.е. исполнить при помощи автоматически сгенерированных веб-форм) от начала и до конца - тогда в результате получится нечто жизнеспособное. Полностью согласен с тем, что лучше разбираться с одним критичным, чем распылять усилия на "все" процессы. Да, это уже можно назвать результатом проектирования. Насколько я знаю арис этого не умеет. Что это умеет? ЗЫ нашел интересную ветку по теме BPMS и роль программистов ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 18:32 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
"Это" должна уметь любая BPM-система, и я имел возможность убедиться в том, что многие действительно умеют. Правда не все системы одинаково доступны. Например очень хотелось бы попробовать Lombardi, а взять негде. Из доступных могу посоветовать Unify. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 18:39 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73ЗЫ нашел интересную ветку по теме BPMS и роль программистов Я б почитал другую ветку по данной теме http://sql.ru/forum/actualthread.aspx?tid=259891&hl=%ef%f0%ee%e1%e0+%f1%e8%eb ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 21:25 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
andbary<...> На практике проходил подобный подход 3 раза :( Сделал следующие выводы: Попытка увеличить уровень детализации приведет к еще большему количеству "воды". Выделить из того, что получится рациональное зерно невозможно. А может, это были неправильные бизнес-аналитики? Или разобраться в их описаниях у заказчиков не хватило терпения и знаний? andbary Можно: Выбрать "критичный" (по меркам этих консультантов и вашему) процесс (не менее 4 шагов) и заставить их расписать его полностью (до уровня форм пользователей). Ну, я не говорил, что все БП нужно детализировать до такого уровня - разумеется, описание должно соответствовать задачам, приоритетам и ресурсам. С другой стороны, детализированные БП имеют ценность и в отдельности от ИС - например, для оптимизации, мат. моделирования или написания должностных инструкций. Формы пользователей нарисовать? Тогда уж и структуру БД, и другие элементы архитектуры ИС - это ведь разные части единого целого, они отдельно друг от друга не бывают. Значит, кроме бизнес-аналитиков Вам просто нужны ещё и системные аналитики с архитекторами. Если интересен результат - не нужно требовать от людей выполнения несвойственных им функций. АБ<...>"расписывать" на на бумаге и не в visio, а в BPM-системе. Заставить не только расписать, но и пройти (т.е. исполнить при помощи автоматически сгенерированных веб-форм) от начала и до конца - тогда в результате получится нечто жизнеспособное. Полностью согласен с тем, что лучше разбираться с одним критичным, чем распылять усилия на "все" процессы. Если описание БП нужно не только для постоения ИС - зачем загонять его в прокрустово ложе конкретной BPMS? Опять же, если хочется, чтобы бизнес-аналитики и ИС реализовывали - то на самом деле нужно не только исследование бизнес-процессов, но и полный аутсорсинг разработки ИС. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 22:33 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
AlexTheRavenЕсли описание БП нужно не только для постоения ИС - зачем загонять его в прокрустово ложе конкретной BPMS? Но во что-то же его надо загонять? По-моему у прокрустова ложа BPMS есть преимущества перед прокрустовыми ложами Word/Visio/Aris. Бывает конечно что лучший выбор - это бумага с карандашом, но рассматриваемая ситуация похоже другая. AlexTheRavenОпять же, если хочется, чтобы бизнес-аналитики и ИС реализовывали - то на самом деле нужно не только исследование бизнес-процессов, но и полный аутсорсинг разработки ИС. Бизнес-аналитики - реализовывали?! Нет конечно - не реализовывали, а прототипировали. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2008, 23:00 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
iq_73Ситуация: Имеем большое предприятие с несколькими направлениями бизнеса. На предприятии стоит КИС собственного написания, в которой разросшемуся предприятию становится тесно и, которая не может дать всех разрезов отчетности, т.е. сделать бизнес прозрачным. Дорабатывать и перерабатывать смысла уже не имеет, надо писать заново. К аналогичной ситуации фирма, в которой я работаю («IT железяки», 200 чел.), пришла 5 лет назад. Непреодолимое желание руководства сменить КИС было поколеблено финансово-временными характеристиками этого процесса. Стали, потихоньку, «осознавать» собственный бардак. Привлекли собственное консалтинговое подразделение. Получили первый результат… iq_73Естественно на этом фоне появляется консалтинговая группа, которая берет на себя описать бизнес-процессы, оптимизировать работу и помочь во всем в чем только можно. Команда бравых ребят - черный низ, белый верх, серьезный послужной список, уверенная и поставленная речь и прочая пыль в глаза. За достаточное время работы ребята испачкали кучу бумаги. Схемы БП (ARIS), методы оптимизации, отчеты, презентации – деятельность кипит, результатов на A0 валом. Все красивенько, красненьким, зелененьким, стрелочки…, сладкие речи о светлом будущем и т.п. Проанализировали. 70% БП, тем или иным образом регламентированы в КИС и фактически работают «на уровне подсознания» не будучи описаны «красивенько, красненьким, зелёненьким, стрелочками…». Оставшиеся 30% касаются новых направлений: реализация проектов, сервисное обслуживание – КИС первоначально создавалась, как торговая система поставки по заказам. Поняли, что наша КИС не так уж и плоха. Наметили и стали её совершенствовать в части агрегации объектов и усложнения аналитики. В части управления проектами побрели по пути, описанному shelsoft Новый регламент управления проектами, выработка общей терминологии в определениях, ролевые инструкции, изучение общих стандартов и приспособление их под себя. Регламентация организационных процессов согласования документов, разработки планов, контроля их выполнения и проч. Обобщали собственный опыт по организации проектного документооборота и форм документов по проектам – вырабатывали для себя требования к документообороту (проектному) и к форме документов. Процесс «взросления ребёнка» занял почти 4 года. Внедрение организационных регламентов позволило всем участникам БПов разговаривать на одном языке и формулировать задачи, понятные всем и каждому. Стало понятно, какие БП не смогут эффективно работать без автоматизации информационной поддержки (бизнес логики), а какие вполне устойчивы в рамках орг.регламента. Стало ясно, что наша КИС великолепна в части управления фактическими поставками материальных ресурсов и учёта финансовых ресурсов. Наша КИС абсолютно не приспособлена для календарного планирования проектных работ, плановых вариантов оценки затрат, учёта трудовых ресурсов, маршрутизации документов, выдачи и контроля исполнения заданий, как элементов БП. Последний год мы бредём по пути, описанному WJ Дорабатывать нашу КИС под новые функции – выбросить время и деньги. Решили, не маясь глобализмом, подобрать функциональные продукты, желательно на совместимых платформах, перекрывающие наши текущие потребности (наш «уровень зрелости системы управления») и объединить их возможности для расширения функционала КИС (в общем смысле) на управление проектами (первоначальная цель), а также и другие функции (орг.регламенты, например, но в дальнейшем). Выбор - вещь сугубо индивидуальная - для нас был такой: СЭД DocsVision 3.6 – для хранения документов плана проектов и плана управления документацией проектов (избавление от бардака на файловых серверах), конструктор БП для описания взаимодействия пользователей и документов. «Макетированные документы» плана проекта – табличные документы фиксированной структура, ориентированной на автоматизированную обработку, в формате MS Project – календарное планирование работ, назначение ресурсов, расчёты стоимости работ, в формате Excel – ввод исходных спецификаций оборудования и материалов, вывод документов плана проектов в соответствии с бизнес логикой. СУДП – система управления данными проекта – собственная разработка – реализация бизнес логики обработки данных. Пока писал свой пост, дискуссия по теме ушла далеко вперёд. Чувствую себя, как иностранец - искал нужное слово в разговорнике, нашёл, сказал – все крайне удивились «о чём это он?». Моделирование, макетирование, эмуляция, реализация БП вещь великолепная, но, ИМХО, для крупных, стабильных систем управления, для которых структурные изменения и функциональные перераспределения редкость – это большой и стабильный бизнес, для которого БП не прокрустово ложе, а прямая экономия затрат на обучении персонала, вхождения в должность и гарантия стабильности СУ, как нарезанная резьба - сломался винт, взяли новый, вкрутили, всё работает. Это по теме топика, для большого предприятия. А как быть «средним», бизнес которых развивается, СУ меняется по структуре и функциональности, возникают новые направления, отмирают неуспешные, приходит новый менеджмент со своими методами управления? Из «малых» ИС (типа 1С) уже выросли, а до «больших» не доросли? Бросьте, пож-та, ссылку, если эта тема уже обсуждалась на форуме. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2008, 09:25 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
AlexTheRavenА может, это были неправильные бизнес-аналитики? Или разобраться в их описаниях у заказчиков не хватило терпения и знаний? Ну, я не говорил, что все БП нужно детализировать до такого уровня - разумеется, описание должно соответствовать задачам, приоритетам и ресурсам. С другой стороны, детализированные БП имеют ценность и в отдельности от ИС - например, для оптимизации, мат. моделирования или написания должностных инструкций. Формы пользователей нарисовать? Тогда уж и структуру БД, ... Если интересен результат - не нужно требовать от людей выполнения несвойственных им функций. Подчеркну. Я согласен с той теорией которую вы изложили. Вот только я не знаю способа отличить работающие схемы от фигни, до того момента когда эти схемы пойдут в работу. Поэтому и предложил взять в работу критичный процесс и посмотреть, что получится... Разобраться в описаниях значит нарисовать процесс еще раз (другого способа не существует) и потом долго доказывать этим мальчикам, что ты нарисовал правильно (мне это ни разу не удавалось :) ), а вот когда они запускают процесс все становится прозрачно. Уже на этапе запуска местный ИТ отдел поймет, что это, а на этапе тестовой эксплуатации станет ясно и руководству. Пока эти БП не проверены практикой, они НИЧТО... Что то моделировать по кривым схемам, я бы не стал. P.S. Загонять в BPM я бы не стал, я не очень хорошо отношусь к данной методике и считаю ее очень сырой (IMHO). P.P.S. Мой опыт, горькая практика... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2008, 10:25 |
|
Моделирование бизнес-процессов.
|
|||
---|---|---|---|
#18+
andbaryПока эти БП не проверены практикой, они НИЧТО... Что то моделировать по кривым схемам, я бы не стал. Вы понимаете, что проверить процесс можно только запустив его в работу... это хорошо. но с другой стороны запускать его в работу не спешите... andbaryP.S. Загонять в BPM я бы не стал, я не очень хорошо отношусь к данной методике и считаю ее очень сырой (IMHO). ... как следствие andbaryгорькая практика... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2008, 11:00 |
|
|
start [/forum/topic.php?fid=33&msg=35060341&tid=1548643]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
144ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 253ms |
0 / 0 |