Пресловутые бизнес-процессы
- Войдите на сайт для отправки комментариев
И все-таки без описания их - бизнес-процессов ну никак не обойтись. Хотелось бы (пока не привязываясь к пункту ТЗ, а то опять уйдем в дебри) поговорить, посоветоваться, а может, и посоветовать - как же лучше их описывать. Я не хочу, чтобы мне писали про буржуйские методики, про российские стандарты, нет - смотрела. Я хочу чтобы мы рассказали друг-другу простым русским языком, кто что в них увидел...
Я пока что из всех методик ничего лучшего не смогла взять как:
1. интервью;
2. текстовое описание
3. составление схем (схема алгоритма действия - обычная блок-схема + управление - сверху + участники - снизу);
4. высылка на проверку;
5. исправление (и/или новое интервью)
6. и т.д. пока не покажется, что я все описала верно.
7. проверка и исправление того, что написала, пока не покажется, что и другие поймут это правильно.
Вот такой вот ресурс...:
http://vpg.ru/main.mhtml?PubID=143
Вот, собственно, что и требовалось доказать: "модель бизнес-процессов - это, прежде всего, информационная база для аналитика, но не цель проекта" - т.е. за немерянные деньги будут предоставленны красивые картинки (а если повезет, то и анимированные).
А онлайн-калькулятор мне понравился:) - описание (даже не функциональная модель!!!) бизнес-процесса за $100000 для конторы в 1000 человек. Крррасота!
Вот такой вот ресурс...:
http://vpg.ru/main.mhtml?PubID=143
Описание бизнес-процессов относится работ, в которых мы обладаем огромным методическим потенциалом и многолетним опытом.
Как вам? Да и дальше много такого... Мда... И у них ЕСТЬ КЛИЕНТЫ? И их просят ЧТО-ТО описать???
Еще одна книга Елены Сергеевны Вентцель
"Исследование операций" была переиздана в 2004 г.
http://www.bolero.ru/index.php?SID=3b13730d6fdef1536522b7b92cbdf006&level=4&pid=36676432
Купил и читал с удовольствием как худ.лит.
Они наверно не видели: Вентцель Е.С. Теория вероятностей. После его изучения, оказывается эта наука не такая страшная.
У меня была эта книга. Отдал приятелю, уже и не помню, по какому поводу - надо ему было. Так у него и осела 
Самое смешное - курс теории вероятностей нам не читали То, что не было сопромата и начерталки - понятно, факультет-то радиоэлектронный. Было много всяких спецфизик и спецматематик, а по теории вероятностей прошелся только Барзилович (вероятность отказов БРЭО, предпосылок к летным происшествиям и т.д.)
yuzh
"...Просто неравнодушен я к печатному слову..."
Посмотрел архивы (памяти своей тоже) нигде нет ссылки на лит-ру (исключая тех 3-4), с вероятностью 0.9 это компиляция.
Не понимаю авторов учебников по теории вероятностей (не прикладников). Они наверно не видели: Вентцель Е.С. Теория вероятностей. После его изучения, оказывается эта наука не такая страшная.
Будучи адъюнктом, спускался из "скворечника" (комната для адъюнктов над крышей второго фак-та). Идет полковник Монсик В.Б. (читал у нас курс по этой самой теории и, если не ошибаюсь, учился у Елены Сергеевны) спрашивает:
- Ну что монетку нашел?
- Какую?
- Которую Елена Сергеевна бросала.
Оказывается она в этом "скворечнике" тоже была.
Рикки. Пожалуйста
13. Вентцель Е.С. Исследование операций; задачи, принципы, методология. М: Наука, 1980.
Ох уж эта Елена Сергеевна Начальник нашей военной кафедры полковник и дважды доктор Е.Ю. Барзилович упоминал о ней почти на каждом занятии
Кстати, она еще и автор небезызвестной Кафедры
До сих пор не пойму, как ей дали возможность преподавать в те времена в Жуковке и написать кучу книг по теории вероятностей.
Возможно поможет Вам.
Спасибо, посмотрела навскидку - вроде, действительно, может пригодится.
У меня, правда, противоположный Yuzh-у подход - все отсеивается, не задевая, но если что-то хоть немного может пригодиться,связывается с задачей "как бы" само собой и заседает крепенько )))
Что-то не нравится?
Помилуйте, как можно... Просто неравнодушен я к печатному слову. Тут, там нахватаешься, а ежели удастся еще сцепить одно с другим - глядишь удастя стать немного просвещенней. 
честно говоря, не помню. При подготовке материала использовалась следующая лит-ра:
1. В.И. Першиков, В.М. Савинков. Толковый словарь по информатике. М: Фи-нансы и статистика, 1995.
2. Гради Буч. Объектно-ориентированное проектирование с примерами приме-нения. М: Конкорд, 1992.
3. Современный словарь иностранных слов. М: Русский язык, 1992.
4. Основы синтеза систем летательных аппаратов. Под ред. Лебедева А.А. М: Машиностроение, 1987.
5. В.М. Агеев, Н.В. Павлова. Приборные комплексы летательных аппаратов и их проектирование. М: Машиностроение, 1990.
6. ГОСТ Р*В* 5*0*8*5*7-96. Комплекс авиационного вооружения. Термины и опреде-ления. М: Госстандарт России, 1996.
7. Словарь по информатики (??????????).
8. Бортовые цифровые вычислительные машины комплексов авиационного вооружения. Под редакцией Мамошина В.Р. М: ВВИА им. проф. Н. Е. Жу-ковского, 1991.
9. Борисов А.М., Вилюмс Э.Р., Сукур Л.Я. Диалоговые системы принятия ре-шения на базе мини-ЭВМ, Информационное, математическое и программное обеспечение. Рига: Зинатне, 1986.
10. Калабухова Е.П. Основы теории эффективности воздушной стрельбы и бом-бометания. М: Машиностроение, 1991.
11. (глава № 6). Саати Т.Л. Математические методы исследования операций. М: Воениздат, 1963.
12. Воднев В.Г., Наумович А.Ф., Наумович Н.Ф. Математический словарь выс-ший школы. М: Издательство МПИ, 1989.
13. Вентцель Е.С. Исследование операций; задачи, принципы, методология. М: Наука, 1980.
14. Реклейтис Г., Рейвиндран А., Рэгсдел К. Оптимизация в техники. М: Мир, 1986.
15. Математика. Большой энциклопедический словарь. Под ред. Прохорова Ю.В. М: Большая Российская энциклопедия, 1998.
16. Носач В.В. Решение задач аппроксимации с помощью персональных компь-ютеров. М: Бином, 1994.
17. Попов Э.В., Фоминых И.Б., Кисель Е.Б., Шапот М. Д. Статические и динамические экспертные системы. М: Финансы и статистика, 1996.
18. Гусева Т.И., Башин Ю.Б. Проектирование баз данных в примерах и задачах. М: Радио и связь, 1992.
19. Макетирование, проектирование и реализация диалоговых информационных систем. Под ред. Е.И. Ломако. М: Финансы и статистика, 1993.
20. Мешалкин В.П. Экспертные системы в химической технологии. М: Химия, 1995.
и ещё не указаны 3-4 книги, так как на данный момент нет точных данных.
Что-то не нравится?
При построении функциональной структуры использую следующий подход, иногда помогает. правда он здесь приведен без примера
Под функциональной структурой автоматизированной системы (АС) понимается абстрактная модель, устанавливающая состав и порядок взаимодействия задач, решение которых обеспечивает АС.
А не подскажете, из какого опуса позаимствована цитата?
Уважаемая Рикки, вот нашел следующее http://khpi-iip.mipk.kharkiv.edu/library/case/index.html.
Возможно поможет Вам.
Я дико извиняюсь, но как бы термин ПОТОК ДАННЫХ (Data Flow) уже успели застолбить буржуи и даже две нотации таких диаграмм - Йордана, а также Гейна-Сарсона.
В общем, спасибо всем, хоть и разошлись не только во мнениях, но в терминологии - я вот думаю... может, надо начинать тему с... глоссария???
Рисую диаграммку потоков данных пользуясь... нотацией Гейна-Сарсона (Чуть не написала Гей-Люссака 
) - надо же с чего-то начинать 
.
Так что особое спасибо Yuzh-у (и Гейну-Сарсону тоже )))
Например, процесс расчета заработной платы.
функциональная структура (модель) на "естественном языке" здесь
http://webfile.ru/914567
ошибка: не провел одну линию
SergeyL написал:
БП является абсолютно абстрактным понятием
Мммм... а как вы называете тот РЕАЛЬНЫЙ ПРОЦЕСС, который автоматизируете? Например, процесс расчета заработной платы.
Замечательно называется просто "Расчет заработной платы". А описание того, что модно называть БП, может термин "бизнес-процесс" не содержать вовсе и называться, например: "Порядок расчета заработной платы".
Весело.
Начала топ, чтобы "БЕЗ УМНИЧАНИЯ" и кидания словами переговорить о том, кто и как все же начинает описывать задачу
А вот это Вы как раз заявляете впервые - прочтите начало треда. Вы как раз просили побакланить про бузинес-процессы. Бузинес-процессы - они сами по себе, а задача, она сама по себе.
Честно скажу, в нашей конторе сначала чего-то пишут не очень много и это чего-то лучше всего потом выбросить. Трудящим писать на русском техническом языке в огромную падлу (sorry), а в кайф им программить, ковыряться руками в БД, оси приворачивать. Затем, когда уже все готово и спихнуто в опытно-промышленную эксплуатацию пишут нечто невнятное с заголовком ТЗ, его суют кому-то высокому (главинжу) на подпись, и он не читая подписывает. Затем мастрячат АКТ приема- сдачи, все чинно кладут в папочку и на полочку, а в это время затыкают дыры (и даже ночью - что делать произсводство непрерывное). Инсайдеры мы, в отличие от аутсорсеров (вовремя удержался, чтобы не написать "аутсайдеры" )
Вот например, Вы описываете процесс: "Дядя Вася подходит к дяде Пете, дает ему подзатыльник, после чего дядя Петя переходит в рабочее состояние, берет лопату и начинает копать."
Коллега, Вы излишне упрощаете. Нужно так:
1. Человек на должности, которую нынче занимает дядя Вася, по наступлении определенного события, скажем, начало предвкушения проверки кем-то более вышестоящим, подходит к работнику в должности, которую занимает нынче дядя Петя, и дает последнему подзатыльник.
2. Работник в должности, которую занимает нынче дядя Петя, после получения подзатыльника переходит в рабочее состояние.
3. Работник в должности, которую занимает нынче дядя Петя, после перехода в рабочее состояние начинает копать, и копает, копает...
:D:D
SergeyL написал:
БП является абсолютно абстрактным понятием
Мммм... а как вы называете тот РЕАЛЬНЫЙ ПРОЦЕСС, который автоматизируете? Например, процесс расчета заработной платы. И что Вы собираетесь сначала делать - строить МОДЕЛЬ РАСЧЕТА или сразу приниматься за построение модели системы, которая будет рассчитывать и выдавать все отчеты???
Или, например, документооборот. ОН РЕАЛЬНО существует на предприятии? Или это АБСТРАКТНАЯ СУЩНОСТЬ? Вы что, не анализируя, куда какой документ пойдет и в какой момент будет подписан, будуте сразу моделировать структуру АС???
БП является абсолютно абстрактным понятием
Мммм... а как вы называете тот РЕАЛЬНЫЙ ПРОЦЕСС, который автоматизируете? Например, процесс расчета заработной платы. И что Вы собираетесь сначала делать - строить МОДЕЛЬ РАСЧЕТА или сразу приниматься за построение модель системы, которая будет рассчитывать и выдавать все отчеты???
Или, например, документооборот. ОН РЕАЛЬНО существует на предприятии? Или это АБСТРАКНАЯ СУЩНОСТЬ? Вы что, не анализируя, куда какой документ пойдет и в какой момент будет подписан, будуте сразу моделировать структуру АС???
Сдается мне, что ВСЕ участники этой дискуссии говорят о разных вещах и не понимают друг друга - эдакий разговор слепого с глухим:)
Наверное, стоит остановить топик именно на этом. Топик в тупике.
Весело.
Начала топ, чтобы "БЕЗ УМНИЧАНИЯ" и кидания словами переговорить о том, кто и как все же начинает описывать задачу, в итоге получилось все с точностью до наоборот - много "умных слов", а информации - ноль.
Такое впечатление, что что меня (или друг-друга) пытаются учить уму-разуму... к чему? Мне это не надо. Да и никому, я думаю. Читать умею. Уже давно. Разобрать, что есть "схема в нотации Йордана де-Марко" человеку, если он не дурак и хоть немного технарь, достаточно нескольких минут, ничего нового я там не увидела.
А может, уважаемые (не все, правда) решили просто поприкалываться? Зачем именно здесь?
модель (не чего-то там), а именно автоматизированной системы все-таки должна строиться ПОЗЖЕ, чем модль процесоов, которые она будет автоматизировать.
Вот теперь я окончательно запутался... А при чем здесь тогда БП?
Сдается мне, что ВСЕ участники этой дискуссии говорят о разных вещах и не понимают друг друга - эдакий разговор слепого с глухим:)
Лично я согласен с yuzh - БП является абсолютно абстрактным понятием, которое может одновременно говорить обо всем и ни о чем. Это, кстати, следует из определения БП.
Бузинес-процессы - это тоже абстрация
1. Процессы не могут быть абстракцией, а вот их модель - да.
2. модель (не чего-то там), а именно автоматизированной системы все-таки должна строиться ПОЗЖЕ, чем модль процесоов, которые она будет автоматизировать.
3. А если кто-то кого-то лопатой прихлопнул, а мы такой возможности не учли, значит мы просто плохую модель нарисовали, вот и все. Я не поняла, что показывает этот пример...
SergeyL написал:
но там нет ни слова о бизнес-процессах, а только о построении функциональной модели, что, на мой взгляд, гораздо ближе к теме, чем пустая болтология о BPM.
Посторение фукциональной модели - конечно, это ближе к теме, но.
Строить функциональную модель системы все-таки нужно ПОСЛЕ того, когда построена модель процессов, которые мы будем автоматизировать, разве не так?
Бузинес-процессы - это тоже абстрация (кстати, некоторые далеко продвинутые отечественные перцы отрицают такую абстракцию - это я не про себя :oops: ) модель. Отчего не помоделировать в других абстракциях?
surgeon написал:
Цитата:
ГОСТ 28195-89 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Нас учили в ВУЗе, что specification есть технические требования Короче - масло масляное получается
Я дико извиняюсь, что влезаю в столь ученый спор, но вот у проклятых буржуев, судя по упоминавшимся мной ранее публикациям, требования - это требования к системе, выраженные на языке предметной области и понятные всем заинтересованным сторонам, определяет функциональность системы и ее эксплуатационные свойства. А спецификация требований, это те же требования к системе, пересказанные на языке или в обозначениях, понятных разработчикам. Процитирую "Быстрое тестирование"
Спецификация требований, или функциональная спецификация, - это далеко не примитивный перевод определений требований на технический язык. Спецификация может проиводить дальнейшее разбиение требований по категориям, а также добавлять подробности за счет формулирования некоторого набора производных требований. Например, в исходном определении требований может быть указано, что система должна работать в заданном диапазоне температур, в то время как в спецификации могут быть определены различные режимы эксплуатации системы в различных температурных диапазонах. В какой-то мере определение требований представляет собой объявление того, что заказчику необходимо и что он хотел бы получить, а спецификация есть ответное предложение группы специалистов, содержащее описание того, что будущая система будет способна делать.
Я чего-то не понимаю - а об чем, собственно, спор?
Но, все ж, влезу... тож поумничаю:)
Словарь Лингво:
specification [ ]
1) спецификация, детализация; детализирование ( действие, процесс ) Syn: working out in detail , detailed elaboration
2) а) подробное изложение ( of - чего-л. ) б) деталь, подробность ( контракта и т. п. )
ГОСТ 2.102:
Спецификация - Документ, определяющий состав сборочной единицы, комплекса или комплекта
и даже ГОСТ 21.110 (хотя строительство тут и ни при чем:) )
Спецификация оборудования, изделий и материалов — текстовый проектный документ, определяющий состав оборудования, изделий и материалов, предназначенный для комплектования, подготовки и осуществления строительства
Повторюсь, и о чем спор? :)[/b]
Строить функциональную модель системы все-таки нужно ПОСЛЕ того, когда построена модель процессов
ДО ТОГО КАК...
Смоделировав функционирование чего-либо, устранив все узкие места, Вы сможете спокойно описать это и обозвать как угодно (нравится Вашему начальству слово "бизнес-процесс" - называйте).
А искать формализацию этому заморскому чуду - дело неблагодарное, т.к. оновой не существует:)
Вот например, Вы описываете процесс: "Дядя Вася подходит к дяде Пете, дает ему подзатыльник, после чего дядя Петя переходит в рабочее состояние, берет лопату и начинает копать."
Вы это описали, утвердили, на этой основе строятся другие процессы и работа организации в целом.
А вот дядя Петя возьмет лопату и проломит череп дяде Васе за подзатыльник... И что тогда?
Цитата:
ГОСТ 28195-89 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Нас учили в ВУЗе, что specification есть технические требования Короче - масло масляное получается
Я дико извиняюсь, что влезаю в столь ученый спор, но вот у проклятых буржуев, судя по упоминавшимся мной ранее публикациям, требования - это требования к системе, выраженные на языке предметной области и понятные всем заинтересованным сторонам, определяет функциональность системы и ее эксплуатационные свойства. А спецификация требований, это те же требования к системе, пересказанные на языке или в обозначениях, понятных разработчикам. Процитирую "Быстрое тестирование"
Спецификация требований, или функциональная спецификация, - это далеко не примитивный перевод определений требований на технический язык. Спецификация может проиводить дальнейшее разбиение требований по категориям, а также добавлять подробности за счет формулирования некоторого набора производных требований. Например, в исходном определении требований может быть указано, что система должна работать в заданном диапазоне температур, в то время как в спецификации могут быть определены различные режимы эксплуатации системы в различных температурных диапазонах. В какой-то мере определение требований представляет собой объявление того, что заказчику необходимо и что он хотел бы получить, а спецификация есть ответное предложение группы специалистов, содержащее описание того, что будущая система будет способна делать.
но там нет ни слова о бизнес-процессах, а только о построении функциональной модели, что, на мой взгляд, гораздо ближе к теме, чем пустая болтология о BPM.
Посторение фукциональной модели - конечно, это ближе к теме, но.
Строить функциональную модель системы все-таки нужно ПОСЛЕ того, когда построена модель процессов, которые мы будем автоматизировать, разве не так?
Но ведь ваша контора, судя по Вашей растерянности, обходилась без них до этого, ведь так?
Бизнес-процессы - это в общем-то объективная реальность, как бы мы их ни называли. И ни одна контора БЕЗ НИХ не обходится. Другое дело, описывали ли их...
О КАК. Мои попытки попробовать опросить коллег, как они это делают (описывают б/п) расценены как растерянность. Грустно. Нет, уже года три не обходимся БЕЗ ОПИСАНИЯ Б/п... И растерянности никакой - я в общем-то это делаю... и с успехом.
Как-то я, наверное, неправильно выражаю свои мысли... :roll: грустно... писатель, блин
yuzh написал:
Рикки, а еще меня мучит любопытство, а нафига Вам сдались эти чертовы бизнес-процессы? :oops: Я вот как-то все больше вижу, что они Вам мешают, так может ну их.
ЭЭЭЭЭЭЭЭ... действительно, ну их, эти процессы, будем писать прогу про что хотим и для чего хотим )))
Но ведь ваша контора, судя по Вашей растерянности, обходилась без них до этого, ведь так? А Вы (Ваш бугор), наверное, хотите построить коллег разработчиков на новый лад через выявление бузинес-процессов? А они прониклись? Поди сказали: а напиши нам подробну инстру, как нам энти бузинес-какихтам вычиплять? Труба однако таким бузинес-процессам - тихий саботаж он всегда с нами.
Pикки написал:
Я дико извиняюсь, но как бы термин ПОТОК ДАННЫХ (Data Flow) уже успели застолбить буржуи и даже две нотации таких диаграмм - Йордана, а также Гейна-Сарсона. И, ну я прям не знаю что делать, операции там имеют место быть под названием ПРОЦЕСС
Ну не нужны мне ОПЕРАЦИИ - это будет следующий этап, когда я каждый поток буду раскладывать более подробно.
В общем, пока что я все больше и больше прихожу к выводу, что ну их... диаграммы Йорд...Гей...Сар...
Надо просто немного подумать. И все! Кружочки - МЕСТА входа и выхода, квадратик - узловые МЕСТА. И стрелочки между ними. И ВСЕ - не надо изучать методики и "прогибаться под них". Осталось всего-ничего - ТОЧНО определиить входы-выходы и все узлы. А это сделать никакая методика не поможет, разве что... хм... мозговой штурм... НАТСа что ли наесться???
Рикки, а еще меня мучит любопытство, а нафига Вам сдались эти чертовы бизнес-процессы? :oops: Я вот как-то все больше вижу, что они Вам мешают, так может ну их.
ЭЭЭЭЭЭЭЭ... действительно, ну их, эти процессы, будем писать прогу про что хотим и для чего хотим )))
Нас учили в ВУЗе, что specification есть технические требования
А есть у Вас такой ГОСТ? Сбросить можете на всеобщее обозрение? vk собака ergd точка ru
Полное наименование стандарта, на который я ссылался:
ГОСТ 28195-89 ОЦЕНКА КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ. Общие положения
Он у вас уже был выложен недавно. Кстати, большое спасибо.
Что касается СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ - то такого типа проектной документации действующие в РФ стандарты не предусматривают, ИМХО. Знаю только про ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ, ТЕХНИЧЕСКИЕ УСЛОВИЯ. ТЕХНИЧЕСКИЕ ЗАДАНИЯ.
К великому сожалению не могу у себя найти тот нормативный документ, где рекомндуется употреблять термин СПЕЦИФИКАЦИЯ с "оглядкой" на ЕСКД.
Цитата:
ГОСТ 28195-89 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Нас учили в ВУЗе, что specification есть технические требования Короче - масло масляное получается
Нас учили в ВУЗе статистике, но немного учили в КБ правилам оформления конструкторской документации
Осмелюсь оспорить Спецификация в ЕСКД есть перечень (в грубой трактовке) неких документов, покупных изделий и т.д. Что и подразумевал ENPRON
Спецификация требований читай перечень требований, и никакого масла
ГОСТ 28195-89 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ
Нас учили в ВУЗе, что specification есть технические требования Короче - масло масляное получается
А есть у Вас такой ГОСТ? Сбросить можете на всеобщее обозрение? vk собака ergd точка ru
И почему это "спецификация" - с осторожностью - уже столько лет без всякой осторожности употребляется - и ничего...
СПЕЦИФИКАЦИЯ - по ЕСКД это наменование основного конструкторского документа для сборочных единиц. Еще в хозяйственных договорах бывают наименованные так приложения, где перечисляются ПРЕДМЕТЫ.
В каких-то последних гостах-переводах употребление этого слова как синонима для перечня требований не рекомендовалось в виду вышеописанной практики принятого отечественного употребления.
К сожалению, ссылку на этот абзац не нашел.
Правда, в исконном отечественном ГОСТ 28195-89 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ упоминается в Приложении 2 (справочном )
как один из результатов Фазы Анализа:
"определение требований,
спецификация требований,
техническое задание "
Но здесь это все-таки результат процесса анализа, а не наименование типа проектного документа.
Только в этом смысле и шла речь об определенной осторожности употребления этого нестандартизованного термина.
Ладно. Проще. Пример.
Надо изобразить ПОТОКИ ДАННЫХ, только потоки и все - без операций. Как не изобретать велосипед и чем мне здесь могут помочь пресловутые методики???
Я дико извиняюсь, но как бы термин ПОТОК ДАННЫХ (Data Flow) уже успели застолбить буржуи и даже две нотации таких диаграмм - Йордана, а также Гейна-Сарсона. И, ну я прям не знаю что делать, операции там имеют место быть под названием ПРОЦЕСС, который представлен глаголом (в кружочке или квадрастике) и обозначает продуцирование выходных потоков данных из входных. Это я открыл книгу г-на Колянова "Консалтинг при автоматизации предприятий" на странице 38.
Рикки, а еще меня мучит любопытство, а нафига Вам сдались эти чертовы бизнес-процессы? :oops: Я вот как-то все больше вижу, что они Вам мешают, так может ну их.
Ладно. Проще. Пример.
Надо изобразить ПОТОКИ ДАННЫХ, только потоки и все - без операций. Как не изобретать велосипед и чем мне здесь могут помочь пресловутые методики???
Карл Вигерс - это точно рулез для разработки спецификаций требований к ПО. Но не в рамках требований ГОСТ 34/19.
Да и сам термин "спецификация" у нас надо употреблять с известной осторожностью.
ПРИЕХАЛИ.
Пытаюсь докричаться - ребяты!!! я не о том!!! для требований (ТЗ) мне ГОСТа выше крыши хватит, я про описание БП... и только, остальное - в других темах...
И почему это "спецификация" - с осторожностью - уже столько лет без всякой осторожности употребляется - и ничего...
А затем еще вот на книгу К.Вигерса разорился "Разработка требований к ПО" - это, на мой взгляд, почти повареная книга...
Карл Вигерс - это точно рулез для разработки спецификаций требований к ПО. Но не в рамках требований ГОСТ 34/19.
Да и сам термин "спецификация" у нас надо употреблять с известной осторожностью.
к предыдущему и к тому, как давно (лет 30 уже...) и с какого возраста народ узнает о способе записи алгоритмов:
ЦИТИРУЮ...
Использование в качестве компьютерной поддержки курса «Роботландии», а именно сложного исполнителя Кукарача, а позднее и Корректора (4-5 класс), дает возможность усвоить учащимся основные понятия. А именно: понятие алгоритма и исполнителя; модель компьютерного управления исполнителем; способы записи алгоритма: текст, блок–схема, программа; понятия рекурсии и рекурсивного алгоритма; понятие ветвления: полной и сокращенной формы и сложных развилок; понятие цикла и циклических алгоритмов; два вида повторения; составление сложных алгоритмов для исполнителя и решения поставленных задач.
Попробую все же объяснить, почему подняла эту тему.
В свое время, как смогла, сделала свое первое описание бизнес-процесс. Пыталась читать в форуме Философта умные размышления по поводу "буржуйских" (с легкой руки Surgeona) методик. Меня там все пугало - о, диаграммы, о, юз-кейсы.... о, не по-русски что-то... о - то, о - сё... А когда немного разобралась - ну надо же!!! Я, оказывается, это все в том или ином виде использовала в первом же неопытном описании - мне с умным видом пытаются втолковать:
"На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали"
Да я уже лет 12 знаю и использую блок-схемы... и покруче, пожалуй, этих...
или - "Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления."
Сколько умных слов для того, чтобы объяснить давно всем известный принцип ветвления...
"UC - это ТАКОЕ... да нет, это ТАКОЕ... ох, это что такое!!!"
А вы знаете, что бухучет в самых захудалых учебных заведениях уже лет 50 ведется на "сквозных примерах" - чем не юз-кейсы.
Я не собираюсь гнуть пальцы - о какая я умная, отнюдь. Больше того, я все еще надеюсь, что найду что-то и возьму для себя в этих методиках. Я буду, конечно, просматривать еще и еще эти методики, но... хороши бывают не методики, а те, кто с умом применяют их. И вот что я подумала - ведь здесь, в форуме, столько светлых голов, которые не кидаются иностранными словами, а пишут умные ТЗ и умно описывают бизнес-процессы. Чем мы хуже "буржуйских" методологов? ДА НИЧЕМ!!! Разве тем, что не опубликовали свои находки или хорошо забытое старое, чему нас давно уже учили, назвав это другими словами.
Может быть, кому-то мои "рассуждения" покажуся рассуждениями новичка или, например, не в меру самоуверенными или резкими. Приглашаю к полемике.
SergeyL
....только о построении функциональной модели, что, на мой взгляд, гораздо ближе к теме, чем пустая болтология о BPM.
При построении функциональной структуры использую следующий подход, иногда помогает. правда он здесь приведен без примера
Под функциональной структурой автоматизированной системы (АС) понимается абстрактная модель, устанавливающая состав и порядок взаимодействия задач, решение которых обеспечивает АС.
Формирование функциональной структуры (АС) удобно рассмотреть с позиций математического обеспечения, которое в современных АС может быть представлено в виде трех уровней абстракций:
1) математическое описание задачи – совокупность математических зависимостей, описывающих процесс решения задачи. Такое описание является общим и не конкретизируется типом АС и её особенностями;
2) алгоритмы задачи АС, то есть совокупность математических и логических операций, выполняемых в определенной последовательности и приводящих к решению задачи в конкретной АС;
3) программы, реализующие алгоритмы задачи, разрабатываются на основе алгоритмов с учетом конкретного типа ЭВМ, их программного обеспечения и возможностей организации вычислительного процесса.
Основой математического обеспечения задач является описание задач на естественном языке. Таким образом, функциональная структура АС, в зависимости от уровня абстракции, может быть представлена как:
- функциональная структура АС описания функционирования АС на естественном языке;
- функциональная структура АС математического описания функционирования АС;
- функциональная структура АС алгоритмического описания функционирования АС;
- функциональная структура АС программного описания функционирования АС.
В свою очередь, функциональную структуру АС удобно и наглядно представлять в виде иерархии. Иерархическая форма организации функциональной структуры АС предусматривает её построение в виде уровней с координированием «сверху – вниз». Элементом уровня считается объект, не подлежащий декомпозиции на данном уровне иерархии. При формировании объектов, в первую очередь, учитываются отношения между объектами. Причём, отношения между объектом, находящегося на n уровне, с объектами, находящимися на n+1 и n-1 уровнях, более взаимозависимы, чем отношения между объекта находящимися на одном уровне. Более того, между объектами, находящимися на одном уровне, отношения могут вообще отсутствовать. Отметим еще одну особенность. Управление в данной иерархии осуществляется на основе принципа «сверху - вниз», но при формировании самой иерархии возможно совместное использование принципов построения «сверху - вниз» и «снизу – вверх».
Рассмотрим функциональную структуру АС иерархического вида, состоящей из четырёх уровней классов:
- классы описания задач (на естественном языке, математического, алгоритмического, программного);
- классы описания режимов (на естественном языке, математического, алгоритмического, программного);
- классы описания устойчивых состояний (на естественном языке, математического, алгоритмического, программного);
- классы описания частных блоков (на естественном языке, математического, алгоритмического, программного).
На первом, самом высоком уровне иерархии, располагаются классы описания задач. Экземплярами класса описания задач являются задачи, решение которых обеспечивает АС. При чем одни задачи решаются постоянно в процессе функционирования АС, а другие – только тогда, когда в этом возникает необходимость. Функционирование АС может быть представлено как процесс последовательного и (или) параллельного решения задач.
В свою очередь, большинство задач состоят из режимов. В соответствии с этим на втором уровне размещается классы описания режимов. Экземплярами класса описания режимов являются режимы определённой задачи. Условием принадлежности того или иного режима к определённой задаче является его несовместимость по времени с другими режимами данной задачи. Следовательно, задача представляет собой группу режимов, несовместимых по времени.
В процессе реализации режима задачи, АС находится в одном из устойчивых состояний. Под устойчивым состоянием системы понимается однотипный набор совершаемых действий и выдаваемых сигналов по отношению к управляемому объекту. Эти действия и сигналы обеспечиваются одним и тем же набором решаемых математических и логических зависимостей. В соответствии с этим на третьем уровне иерархии классов находятся классы описания устойчивых состояний. Экземплярами класса описания устойчивых состояний являются соответствующие режиму устойчивые состояния системы. При возникновении тех или иных событий происходит изменение ситуации и, следовательно, должно измениться состояние АС. Таким образом, режим представляет собой набор устойчивых состояний, связанных последовательностью сигналов, определяющих переход объекта (АС) из одного состояния в другое, при смене ситуации (то есть при возникновении событий). Экземпляры классов описания устойчивых состояний являются функциональными и логическими единицами при анализе и описании АС.
В свою очередь описание устойчивых состояний представляется в виде совокупности частных блоков, автономных по управлению. Каждому состоянию соответствует определенный набор блоков, причем некоторые блоки могут участвовать в описании нескольких различных состояний. Следовательно, на самом низком уровне иерархии находятся классы описания частных блоков. Экземплярами классов описания частных блоков являются элементарные блоки (операции), предназначенные для выполнения конкретной элементарной задачи.
Итак, задачи решаются постоянно или в определенный (заданный) промежуток времени, путём включения соответствующих режимов. Выбор режима задачи осуществляет оператор АС с помощью соответствующих органов управления. Переход из одного устойчивого состояния АС в другое осуществляется автоматически, при выполнении контролируемого события (действия). Устойчивое состояние, в свою очередь, определяет набор выполняемых частных блоков (операций). Таким образом, на верхних уровнях иерархии решение на управление принимает оператор и с понижением уровня иерархии степень автоматизации увеличивается.
Уважаемая Рикки, я не вполне понял о чем конкретно речь, но понял, что это крик или даже скорее тяжкий вздох души.
Уважаемый Yuzh!
Конкретно речь о конретных описаниях бизнес-процесов - как сделать их (не б/п, а описания) не такими мучительными. Вздох - да, вздох был, т.к. как раз в то время я собиралась начинать очередное описание
а некоторые предлагают не описывать, а моделировать.
Описывать, моделировать - какая разница??? Любое описание есть модель.
Я-э-мнэ... ну вот не знаю, в разрез ли э-э Вашего пожелания?
Конечно! Но все равно спасибо . Пролистать и подумать - "а может, в этом что-то есть" - это тоже метод.
Глянув этак прищурившись на приведенный перечень, отчего-то я подумал, что Вас интересуют приемы (методы) сбора требований.
Не совсем. Меня больше интересуют методики именно ОПИСАНИЯ, сбор увы, у меня может быть только таким - интервью и просмотр того, что уже существует в других системах. Мозговой штурм у меня пока что может быть только... с Рикки - т.к. для мозговового штурма, как минимум требуются мозги... или желание их включать для задачи, которая считается МОИМ ДЕЛОМ, совещание - да, с моим боссом, это обязательно.
Еще меня интересует - но это уже из области фантастики - метод оценки АДЕКВАТНОСТИ ПОНИМАНИЯ бизнес-процессов. Я уже не говорю об оценке АДЕКВАТНОСТИ самих б/п.
Или я не о том? А о чем тогда?
Да, действительно, о чем это ВЫ тогда... :roll: увы, это можете сказать только ВЫ
Уважаемая Рикки, я не вполне понял о чем конкретно речь, но понял, что это крик или даже скорее тяжкий вздох души.
И все-таки без описания их - бизнес-процессов ну никак не обойтись.
Ну, если только так категорично... А вот некоторые утверждают, что просто удобно, а некоторые предлагают не описывать, а моделировать.
Хотелось бы (пока не привязываясь к пункту ТЗ, а то опять уйдем в дебри) поговорить, посоветоваться, а может, и посоветовать - как же лучше их описывать. Я не хочу, чтобы мне писали про буржуйские методики, про российские стандарты, нет - смотрела. Я хочу чтобы мы рассказали друг-другу простым русским языком, кто что в них увидел...
Я-э-мнэ... ну вот не знаю, в разрез ли э-э Вашего пожелания?.. А я вот, как отошел от непосредственной этой деятельности немного в сторону, так в маршрутке сначала прочел (каюсь - буржуйскую же) книгу "Принципы работы с требованиями к ПО" Уидрига и Леффингвелла - и тут как солнце из-за туч - столь многое стало понятным из предыдущей жизни програмера и девелопера вообще. А затем еще вот на книгу К.Вигерса разорился "Разработка требований к ПО" - это, на мой взгляд, почти повареная книга ("почти" просто от того, что как не приседай или не прыгай, все равно элемент непредсказуемости и творчества остается). И вот только после прочтения этих весьма практичных книг я стал малость понимать наши ГОСТы 34-ой серии и находить в них параллели с изложенным буржуйскими мастерами, причем именно с точки зрения деятельности - что следует или можно сделать, чтобы получать то, что нужно, а не то, что зачастую получается.
Я пока что из всех методик ничего лучшего не смогла взять как:
1. интервью;
2. текстовое описание
3. составление схем (схема алгоритма действия - обычная блок-схема + управление - сверху + участники - снизу);
4. высылка на проверку;
5. исправление (и/или новое интервью)
6. и т.д. пока не покажется, что я все описала верно.
7. проверка и исправление того, что написала, пока не покажется, что и другие поймут это правильно.
Глянув этак прищурившись на приведенный перечень, отчего-то я подумал, что Вас интересуют приемы (методы) сбора требований. А вот буржуи советуют (и описывают) еще совещания и мозговой штурм (помимо Удрига и Леффингвела можно прочитать в книге "Быстрое тестирование" Р.Калбертсона, К.Брауна и Г.Кобба)
Еще добавить можно собственное обучение премудростям предметной области. Или я не о том? А о чем тогда?
Однако, во всех проектах, которые я наблюдал, картинки жили своей отдельной жизнью
Вестимо Программеру надо расписать, что он должен сделать. Буквами. Так, чтобы понял и не задавал глупых вопросов.
набрела вот на что:
http://www.novatelecom.ru/publish.asp
Очень много материалов по формализации бизнес-процессов
есть здесь -
http://www.finexpert.ru
Авторы - Репин и Co. и книги пишут по Б/П и, вообще, живут с этой темы. Посмотрите.
Однако, во всех проектах, которые я наблюдал, картинки жили своей
отдельной жизнью. А реальное дело делалось людьми. которые, сидя напротив друг друга face-to-face, разговаривали. Тоько так к разработчикам и приходило ПОНИМАНИЕ. Сделанное по сложным картинкам либо потом переделывлось либо не использовалось (выбрасывалось).
Определение БП нашел с трудом:
Бизнес-процесс - устойчивый процесс (последовательность работ), соотнесенный с отдельным видом производственно-хозяйственной деятельности компании и обычно ориентированный на создание новой стоимости (например, бизнес-процесс основного производства), иерархия взаимосвязанных функциональных действий, реализующих одну (или несколько) из целей системы, например, выпуск продукции или ресурсное обеспечение выпуска (под продукцией, понимают товары, услуги и документы).
А вот методик по улучшению - валом... Вывод: бизнес-процессы такая же глупость как и СМК, навязываемая с целью выудить лишние денежки (бизнес-процесс основного производства - звучит:), а?).
БЕЗУСЛОВНО, структуру предприятия, взаимоотношения между подразделениями, производственные и технологические процессы должны быть регламентированны... Но не на основе тупых буржуйских рекомендаций, к тому ж по улучшению.
По построению есть стандарт IDEF0 (изданный в 2000-м Гостандартом как РД), но там нет ни слова о бизнес-процессах, а только о построении функциональной модели, что, на мой взгляд, гораздо ближе к теме, чем пустая болтология о BPM.
набрела вот на что:
http://www.novatelecom.ru/publish.asp
Я так думаю, что это производственные либо административные процессы с ПОЛНЫМ их окружением.
Давно уже приходилось проверять технологические карты на советском оборонном предприятии. В принципе, технолог там делал то же, что и я сейчас - описывал (текстово) например, сборку изделия. ТОЛЬКО!!!
1. Не было никаких ветвлений. Если вдруг появлялось "если" все решалось с помощью служебок.
2. Исполнители - работники конвейра. Никакой связи с клиентом!!! Все уже решено...
3. На входе - материалы и комплектующие, на выходе - изделие. И ВСЕ!!! Никаких - "а вруг завтра мы начнем еще на этом же конвейре и красить изделие..." БЫТЬ ТАКОГО НЕ МОГЛО.
4. Единственный документ - эта самая ТК.
Так вот, по-моему, бизнес-процесс это то же + окружение.
И насущная проблема описания их (бп) возникла именно для автоматизации, ибо сказать АС - если вдруг что-то не так пойдет, напиши служебку... наверное, можно... но вряд ли заказчику понравится!
- Войдите на сайт для отправки комментариев
Ага, мне тоже.
Показать его, что-ли, начальству... 
Интересно, а НОРМАЛЬНЫЙ РУССКИЙ язык при описании, они за эти же бабки обещают или сверху набрасывают (это я насчет "относится работ...")?
http://www.littera.ru/