Управленческое консультирование

Aрхив Все выпуски Архив форумов Разделы Управленческое консультирование Методика предпроектного обследования | Библиотека описаний бизнес объектов | IDEF0 и автоматизация | КОНСУЛЬТИРОВАНИЕ В СЕТИ | Консультационная деятельность: ощущения изнутри и восприятие снаружи | ARIS - шаг в будущее или очередная новомодная штучка? | Обнаружение ложных сведений в документах | Что делать с Дон-Кихотом, облеченным полномочиями?.. | Перспективы развития отечественного консалтинга Методика предпроектного обследования By Leo on Вторник, Август 01, 2000 - 12:00: Уважаемые all!!Помогите найти какую нибудь ссылку по методике проведения обследования предприятия с большой организационной разветвленностью.Как после проведения обследования на нижних уравнях переходить к увязке в единый Б-процесс по вертикале?Заранее блогадарен By С.В.Шульгин on Вторник, Август 01, 2000 - 12:00: Да, уважаемый !Колбасит вас не по-детски, извините :-) Никак в "Легио" вас занесло ? By Сергей Колесников on Вторник, Август 01, 2000 - 12:00: Стоимость такой методики - тысяч 100 минимум.Ланиту как консультанту - полагается наценка :-)Если Вы готовы заплатить, то я готов поделиться :-) By Олег Смирнов on Пятница, Сентябрь 08, 2000 - 15:28: Господа, вопрос на засыпку: Можно-ли построить методику предпроектного обслуживания, основываясь исключительно на всестороннем анализе документооборота ? Анализ других сторон не исключается, но может-ли документооборот выступать в качестве некого стержня ППО ? Мысль возникла оттого, что любая хозяйственная (производственная, финансовая, логистическая)операция имеет документ-основание, подтверждение и т.д. Кто-нибудь шел по такому пути ? Заранее спасибо. By Сергей Колесников on Пятница, Сентябрь 08, 2000 - 17:18: Смотря что вы имеете в виду ! Если вы хотите экстрагировать систему управления компанией - то этого будет недостаточно. Если же говорить только об автоматизации того, что уже есть - то можно в существенной степени. By Олег Смирнов on Пятница, Сентябрь 08, 2000 - 20:26: Сергей, в чем вы видите недостаточность ? Любое управленческое событие сопровождается бумажным описателем, а следовательно поддается формализации через документ. By Олег Смирнов on Пятница, Сентябрь 08, 2000 - 20:31: По сути все документы предприятия и являются слабо-формализованной моделью предприятия "как есть". Но для понимания деятельности предприятия необходимы дополнительные телодвижения по увязке слабо формализованных моделей в единую, в частности по которой и будет строится модель "как будет", не важно с автоматизацией или без нее. By Сергей Колесников on Вторник, Сентябрь 12, 2000 - 17:29: Если посмотреть на "модель" управленческого учета, то документооборот имеет прямое отношение только к одной части - к системе "управленческой отчетности". И это только формализованная часть. А есть еще и неформализованная, котрая в документообороте совершенно не отражена. By Олег Смирнов on Вторник, Сентябрь 12, 2000 - 18:18: Да согласен я, просто с анализа документооборота удобно производить раскрутку обследования. Вопрос немного из другой оперы: Сергей, можно-ли говорить что существуют параллельные и взаимозависимые процессы - производственный (основной); планирование, учет, контроль и управление (вспомогательные) ? Если это так, то можно-ли производить раскрутку ППО с любого процесса ? By Сергей Колесников on Вторник, Сентябрь 12, 2000 - 20:10: Эээээээ ...... Не понял ... Может лучше письмом или устно ? By Олег Смирнов on Среда, Сентябрь 13, 2000 - 10:27: Согласен, сегодня прочитал - бред полный. Мозги плавятся и кризис жанра у меня причем... Тем не менее вопрос остается, какую классификацию процессов на предприятии можно предложить ? By Марек on Среда, Сентябрь 13, 2000 - 12:13: Олегу. Вовсе не кризис, Сергей Вас по большей части поддержал. Я тоже поддержу. Без документарной оценки разобраться (как есть на самом деле) невозможно, она первая и главная. Дальнейшие процедуры могут непонадобиться. Правда процедура знакомства с предприятием может зависеть от целей и доступ к внутренним документам может быть закрыт(пример с ОНАКО-их акции на конкурс, а активы уже тю-тю). Но как я Вас понял, Вы не пожарный инспектор а облеченный доверием руководства консультант. Насчет классификации процессов. Похоже Вас заносит в новомодную струю Knowledge Management, или Искусству библиотекарей, по-русски. Есть ведь классика-семь нот называется, есть инвестиционные подходы- по Cash-Flow (операционная, финансовая, инвестиционная деятельности)называется, в конце-концов стандарты IDEF, ФСА на этом сайте и у Димы Рябых. Или у Вас настолько сложная задача, что без академиков никак? By Олег Смирнов on Среда, Сентябрь 13, 2000 - 13:20: Олег - Мареку. Спасибо за поддержку, речь идет именно о методике предпроектного обследования. К сожалению я не знаком с Knowledge Management и работаю по схеме обследования "все в моей голове - перевариваю - решаю". Здесь и кризис. Голова-то не резиновая. В итоге все укладывается "по полочкам", но какой ценой... УВерен, что должен быть инженерный подход по структуризации аналитической информации. А IDEF0 к сожалению ни при чем, никакая модель не может быть умнее автора, это только средство для анализа, тем более в этой нотации можно охватить только часть задачи. By Олег Смирнов on Среда, Сентябрь 13, 2000 - 17:33: Господа, проясните мою непонятку: Что такое функция в контексте "функциональное моделирование"? В моем понимании это словосочетание - абсурд. Поясню: 1) Если подразумевать под функциями функциональные обязанности, то модель - это просто иерархическая структура предприятия с описанием функциональных обязанностей сотрудников и подразделений. 2) Вот пишут : IDEF0 - средство функционального моделирования. Чего ? Как можно замоделировать в IDEF0 функциональные связи ? Это-же бред полный. Какая корреляция между функциями и процессами ? Возможна-ли процессно-функциональная модель "на одном листе" ? Спасибо. By Марек on Среда, Сентябрь 13, 2000 - 18:51: Олегу Старо, как мир. Классический вопрос из семи нот "Сколько у Вас бизнесов (СХЗ)?" до сих бросает в краску. А если спросить "Чем Вы зарабатываете?" Помните, в анекдоте "... Вот на этот прОцент я и живу!" По делу. IDEF не столько метод, сколько способ представления, преобразования. Ключевые понятия в определениях.Не поняв их дальше двигаться нельзя. Впрочем, я бы подвинулся. Геннадий Верников покруче будет, к нему напрямую не пробовали обращаться?(Сергей Колесников Вам уже советовал). Насчет структуризации аналитической информации смешной вопрос:"А чего такого Вы наанализировали, что не знаете куда деть результаты?" И простите за нахальство-совет:"Прежде чем решать задачку, нужно хорошо представлять как использовать результат". В этом смысле инженерные методы лучше научных, они должны иметь практическое значение. Еще короче:"Зачем Вам это?". By Галактионов Антон on Среда, Сентябрь 13, 2000 - 21:50: Олегу Смирнову: Я не вижу разницы между функциональным моделированием и описанием бизнес-процессов. Может Сергей Колесников пояснит нам это ? А IDEF0 я пытаюсь использовать, чтобы при обследовании было проще понять и уточнить требования заказчика. Чтобы он не руками махал и говорил чего он хочет, а взял карандашек и по моей модели стал делать свои замечания. Так получается зафиксированный результат обследования. Но тут есть одна проблема. Диаграммы "по инструкции" надо показывать бизнес-аналитикам, а как правило таковых на наших предприятих очень сложно найти ... By Галактионов Антон on Среда, Сентябрь 13, 2000 - 22:07: Сергею Колесникову : По сути дела, разница между IDEF0 и IDEF3 заключается в наличии перекрестков в последней методологии. Это позволяет наполнить модель дополнительной логикой. Я считал, что IDEF3 это методология описания процессов (скорее технологических, чем бизнеса), а IDEF0 - это описание исключительно бизнес-процессов (на какой-то стадии процесс состоит из функций - разве это не есть функциональное моделирование ?). И вопрос не по существу : Часто в современных материалах используются "модные" слова - функционал системы, корреляция чего-либо. 1. Как математик по образованию, могу сказать что термин "корреляция" полагается использовать применительно к случайным величинам (из теории вероятностей), а заменять им слово "зависимость" или точнее "степень зависимости" не совсем корректно. 2. Термин "функционал" имеет четко определенное значение - функция, которая переводит свой аргумент в вещественнное число. Что тогда понимается под фразой - функционал такой-то системы (АИС) ? Заранее благодарю, хочу пояснить что это не придирка к словам, а просто попытка выяснить для себя терминологию. By Олег Смирнов on Четверг, Сентябрь 14, 2000 - 11:10: Олег-Мареку. Марек, у Вас похоже каша в голове покруче моей... (Ключевые понятия в определениях.Не поняв их дальше двигаться нельзя) Мой вопрос был вполне конкретен и незачем его повторять. (Насчет структуризации аналитической информации смешной вопрос:"А чего такого Вы наанализировали, что не знаете куда деть результаты?") Я знаю что я наанализировал и знаю куда девать результат, поэтому ваш вопрос - без ответа. (И простите за нахальство-совет:"Прежде чем решать задачку, нужно хорошо представлять как использовать результат") Спасибо, очень хороший совет, только кому ? By Олег Смирнов on Четверг, Сентябрь 14, 2000 - 11:14: Олег - Антону.(Я не вижу разницы между функциональным моделированием и описанием бизнес-процессов) Антон, чтобы не видеть разницы, необходимо четко представлять , что такое функция, а что такое процесс. Например Марек этого четко не понимает. By Marek on Пятница, Сентябрь 15, 2000 - 17:35: Олегу. Спасибо, зацепили. Продолжим. Не знаю как поступаете Вы когда в нерезиновой голове каша, а я так: 1. Классификация по группам. 2. Рейтингование однородной информации в группе. 3. Отсечение второстепенного (АБС) внутри групп. 4. Групповой анализ. 5. Отсечение второстепенных групп. 6. Повторение цикла до стадии, когда понятно не только мне, но и клиенту. Исходя из инженерного опыта главным критерием отсечения(рейтингования) считаю практическую полезность. Прочие критерии выбираются из цели анализа, о ней я Вас как раз и спрашивал, а Вы это приняли на свой счет или симитировали отсутствие ответа эмоциональной реакцией. Относительно моего понимания разницы в понятиях "функция" и "процесс" могу навскидку сформулировать так: "процесс имеет длительность, а функция-только аргумент и результат". Или "результат процесса наперед задан, а функции-зависит от переменных". Вот такая термонология. Кстати, соглашусь частично, что введенное в переводе IDEF0 русское понятие "функциональный блок" не совсем идентично англоязычному "activity box". Получилось, что функции раскрываются через процессы. Когда Нас учили математике, то давали сначала элементарные функции, до процессов не многие доучились. От простого к сложному, так сказать. By Олег Смирнов on Суббота, Сентябрь 16, 2000 - 13:11: Мареку. Вот это уже мужской разговор. Несколько академично изложена концепция анализа и "рейтингования", тем менее уже омысленная технология. Не помешал-бы живой пример, Вам не кажется ?(Прочие критерии выбираются из цели анализа, о ней я Вас как раз и спрашивал) Марек, понимаете, если человек всегда доволен результатами своей работы, то он деградирует. Что касается определения функций и процессов, то я как ни странно согласен. Фактически IDEF0 служит для описания процессов, а не функций, а вот способ описания реализован посредством функциональных единиц, которые нужно и понимать в чисто математическом смысле - преобразование входа(аргумент) в выход(результат) посредством механизмов и управляющих воздействий. И не более того. Другое дело, что нельзя влепить на диаграмму процессов ФУНКЦИИ обследуемой системы, например согласно ISO9000 функции управления и функции обеспечения. Классический пример, когда совпадают определения, но разный смысл. Вот еще, Антон Галактионов пишет : (на какой-то стадии процесс состоит из функций - разве это не есть функциональное моделирование ?) Антон, да любой квадратик на IDEF0- диаграмме и есть функциональное представление элемента процесса и не "на какой-то стадии", а на всех. Теперь вопрос Мареку - реально-ли на одной IDEF0-диаграмме адекватно отобразить все процессы, происходящие в обследуемом предприятии (пусть целью обследования выступают все аспекты деятельности предприятия). Поясню - на одной диаграмме легко отобразить основной производственный процесс (скажем торгово-закупочную деятельность). Сможете-ли Вы адекватно отобразить процессы (в рамках одной модели) планирования, бухгалтерского учета, управления и контроля ? Речь не идет о разных моделях с разных ViewPoint. By Marek on Понедельник, Сентябрь 18, 2000 - 11:05: А если вот так. http://www.cfin.ru/management/intro_finfunc.pdf . Карана (у меня тайные сомнения что это на самом деле адаптированный BAIN, "Tools&tech"), 96 год, никаких IDEF, но легко и по-русски, всего два (с учетом бартера-три) основных цикла предприятия. Надо конечно будет занаукообразить и подправить термины и диаграмки по IDEF, но это техника. By P.Velmar on Понедельник, Сентябрь 18, 2000 - 15:24: "Смешались в кучу кони, люди..." IDEF0 не предназначен для описания процессов, а предназначен для построения функциональной модели. Поэтому каждый блок действительно является функцией, а понятия последовательности в модели отсутствует (а какой процесс без последовательности). Но почему то все упорно пытаются описать процессы именно в IDEF0, хотя для этого предназначен IDEF3. И именно потому, что IDEF0 является средством построения функциональной модели, из него легко перейти к ABC анализу. Успехов! By Олег Смирнов on Понедельник, Сентябрь 18, 2000 - 16:10: О ! Еще важное добавление : Процесс имеет длительность (по Мarek,2000) и последовательность (по Velmar,2000). Кто больше ? To Velmar. Согласен, что на верхних уровнях IDEF0 - диаграммы отражается концептуальная часть и "последовательная" часть в чистом виде отсутствует. А на нижних ? А на нижних собственно последовательная развертка. Другое дело, что для отражения параллельных и времязависимых процессов необходима нотация IDEF3 (при описании большинства процессов социальных систем вполне достаточно IDEF0). Таким образом, можно утверждать, что братство IDEF0+IDEF3 в комплексе суть адекватное отображение ПРОЦЕССОВ. By Галактионов Антон on Понедельник, Сентябрь 18, 2000 - 19:06: Для P.Velmar : Дык скажите в чем разница между построением функциональной модели и описанием бизнес-процессов ? By Олег Смирнов on Вторник, Сентябрь 19, 2000 - 14:57: Господин Вельмар, это Ваши слова -(IDEF0 не предназначен для описания процессов, а предназначен для построения функциональной модели)? Тогда будьте добры- удовлетворите желание публики и ответьте на простейший вопрос , я Вам помогу - IDEF0 не предназначен для описания процессов, а предназначен для построения функциональной модели..........(ЧЕГО ?????)......Только не думайте долго - Вы-же знаете ответ ? By P.Velmar on Вторник, Сентябрь 19, 2000 - 17:18: Олегу Смирнову:"предназначен для построения функциональной модели..........(ЧЕГО ?????)......" Ответ очень простой, для построения функциональной модели предметной области. А уж куда Вы его примените, дело Ваше. И не надо меня провоцировать, людей знающих все нет и время тоже не резиновое. Для Антона: Функциональная модель описывает функции, которые должна выполнять система и их взаимосвязь (по входу, выходу, управлению, механизму). Описание процесса состоит в задании правил последовательности исполнения операций (шагов, единиц работы...), а также их исполнителей и объектов, используемых при исполнении операций. Для лучшего понимания рекомендую обратиться к первоисточникам www.idef.com Успехов! By Олег Смирнов on Вторник, Сентябрь 19, 2000 - 18:48: С одной стороны: (IDEFØ is a method designed to model the decisions, actions, and activities of an organization or system) С другой стороны: (As an analysis tool, IDEFØ assists the modeler in identifying what functions are performed, what is needed to perform those functions, what the current system does right, and what the current system does wrong) Справедливости ради должен поблагодарить господина Вельмара за устойчивую позицию, тем не менее :(А уж куда Вы его примените, дело Ваше). Я применяю ЕГО для функционального взгляда на процессы. Хотя нет в IDEF0 "задания правил последовательности"(действительно!), то в IDEF3 нет управляющих воздействий, неадекватно отражаются исполнители, оборудование, тем не менее все упираются , что это описатель процессов. Господин Вельмар, ловите по мылу модель производственных процессов в IDEF0. Успехов ! By Юрий Зеленков on Пятница, Сентябрь 22, 2000 - 12:35: Господа, попробую внести еще больше путаницы в ваши ученые споры. Есть еще такая точка зрения: функции - это тот набор действий, который бизнес-система считает нужным выполнять для достижения своих целей. Естественно, крупные функции (сбыт, производство, закупки...) сегментируются на более мелкие - за которыми закрепляются конкретные исполнители. Процесс же - это тот набор действий, который бизнес-система выполняет при реакции на какое-то внешнее событие (например, получен заказ на поставку продукции). Процессы в идеале должны отображаться на функции, добиться этого отображения и есть задача построения хорошей бизнес-системы. Таким образом, один из жанров управленческого консультирования: берем структуру предприятия (функции), описываем реально выполняемые процессы, "улучшаем" процессы, перестраиваем структуру. Кстати, по поводу IDEF0. По моему опыту разговаривать с заказчиком при помощи таких диарамм дело весьма неблагодарное. Зато есть опыт использования task-flow диаграмм (или activity diagram из UML): после 2-часовой лекции представители заказчика начанают сами описывать свою деятельность, остается только править их экзерсисы с целью согласования и придания блеска. By Галактионов Антон on Понедельник, Сентябрь 25, 2000 - 08:24: Юрию Зеленкову : * представители заказчика начинают сами описывать свою деятельность * Скажите, а какие конкретно представители (директора, начальники отделов, исполнители ...) ? By Юрий Зеленков on Понедельник, Сентябрь 25, 2000 - 14:42: Галактионову Антону: конечно не директора, но исполнители - например, бухгалтера и экономисты. Были случаи, когда диаграммы рисовали и начальники отделов. By Роман Рябой on Понедельник, Сентябрь 25, 2000 - 19:38: Господа, хочу поддержать точку зрения Юрия Зеленкова на процесс. Хотя лично я склонен НЕ употреблять термин "функция" из-за его неоднозначности и предпочитаю все же "действие", "шаг" или "операция", когда речь идет о бизнес-процессе. Относительно понятия "процесс" хотелось бы также добавить, что в классическом определении выполнение б-процесса должно приносить дополнительную ценность (added value) компании. Вот где есть о чем поразмыслить. Что думаете, господа? By Юрий Зеленков on Вторник, Сентябрь 26, 2000 - 14:25: Роману Рябому: Спасибо за поддержку :-). Но кое-что, по-моему, треубется уточнить. Итак, функция -набор действий, которые система считает нужным выполнять. Крупные функции деляться на мелкие до тех пор, пока не получим "элементарные" функции, которые дробить дальше смысла нет. Обычно выполнение элементарных функций вменяется в обязанность конкретным исполнителям (и составляет набор их функциональных обязанностей). Процесс - реакции системы на событие (внешнее, внутреннее, привязонное ко времени). Процесс обычно пересекает несколько функциональных областей и состоит из этих самых "действий" или "шагов" или "операций", которые и имеют измеримый результат. Шаги должны однозначно отображаться на элементарные функции. Очень часто такого отображения нет, и из-за этого возникают проблемы. Таким образом, функциональное моделирование в смысле описания функций смысла не имеет (каламбур :-)). Для этого достаточно взять структуру предприятия и служебные обязанности сотрудников. Имеет смысл функциональное моделирование в смысле описания процессов. По-моему, причина происшедшего выше флейма в том, что спорящие не договорились о терминологии. Относительно дополнительной ценности процессов. Всегда есть два вида процессов - горизонтальные (производство, например), которые увеличивают "ценность" продукта (услуги) для покупателя, и вертикальные (контроль, анализ, управление), которые стоимость продукта увеличивают, но ценности с точки зрения покупателя не прибавляют. By Роман Рябой on Вторник, Сентябрь 26, 2000 - 15:54: Юрию Зеленкову: Привет. 1) В принципе согласен. Я не очень правильно выразился. Я имел в виду, что рассматривая предмет с точки зрения ПРОЦЕССА (особенно с человеком, кому это в новинку, клиентом, например; или сам еще не очень вник) удобнее называть функции, которые (нет спору) входят в процесс, действиями или шагами. Идея в том, что функция, участвующая в процессе, ПРЕВРАЩАЕТСЯ тогда в действие/шаг. Разница -- в восприятии. Говоришь "функция" -- представляешь нечто единичное, говоришь шаг/действие -- представляешь часть ПРОЦЕССА. Говоря функция мы как бы смотрим поперек "линии" процесса, рассекаем ее на независимые составляющие. Говоря шаг/действие мы "смотрим" на ПРОЦЕСС вдоль его "линии" и видим ВЗАИМОСВЯЗАННЫЕ составляющие. Вобщем, те же !"№; , вид сбоку :)). 2) По второму вопросу беру тайм-аут. Оччень это все-таки неочевидно, если хорошо поразмыслить. Соберусь с мыслями - выложу ;) By Галактионов Антон on Вторник, Сентябрь 26, 2000 - 18:09: Юрию Зеленкову : По поводу вертикальных / горизонтальных процессов. Был тут на одной конференции, там про ARIS рассказывали. Так докладчик высказал интересную мысль : ПРОЦЕСС сам по себе плосок и неиерархичен, поэтому использовать иерархии диаграмм для описания ПРОЦЕССОВ не надо. Т.е. ПРОЦЕСС горизонтален и надо использовать как бы горизонтальную иерархию. Что думаете по этому поводу ? By Юрий Зеленков on Среда, Сентябрь 27, 2000 - 12:51: Галактионову Антону: докладчик прав, однако. Другой вопрос, что при множестве процессов на предприятии их надо как-то группировать. Поэтому иерархии все-таки возникают, но "снизу", просто для того, чтобы члены проектной группы могли быстро найти описание того или иного процесса. Иногда это оформляется в виде обобщения процесса как шага процесса более высокого уровня (IDEF0). Для функций же иерархии дело естественное. Теперь о вертикальности/горизонтальности процессов. Так я их назвал просто для того, чтобы различить с точки зрения "привнесения потребительской ценности" в продукт. Горизонтальные ее добавляют, вертикальные - нет, а затраты на создание продукта увеличивают и те, и другие. Вертикальные процессы также плоские и неиерархичные, но посокльку в них участвуют, как правило, начальники (стоящие на разных уровнях функциональной иерархии), то отсюда и название. By Аноним on Среда, Сентябрь 27, 2000 - 17:38: Попробуй полистать книжку Майкл Хаммер и Джеймс Чампи 1993г. “Реинжениринг корпорации” и пр.Методологии там нет, но что-то в терминологии может проясниться. Есть приложения, которые могут помочь со всякими красивостями оформить результат построения бизнес-модели в компании. А вообще, всегда это совместный труд с компанией. Иначе результата не будет. Определена ли цель этого обследования. От этого много зависит в каком виде и в каких срезах делается обследование. Представь весь бизнес компании как многомерный кубик (что ты собственно говоря и делаешь), определи ключевые направления, проговори с заинтересованными лицами. Модель что есть смогут рассказать тебе по всем направлениям ключевые руководители, а вот что хочу,- тут уже хозяев привлекать стоит или того, кто определяет миссию, стратегию компании. Документооборот это хорошо, но часто бывает избыточным. Опять же ЧТО БУДЕТ РЕЗУЛЬТАТОМ РАБОТЫ? Как ты сам для себя ( и руководство) определит что это то, что они ожидали. Успехов. By snake on Четверг, Сентябрь 28, 2000 - 14:47: Господа по самому первому вопросу - лучше разберитесь нужен ли документальный анализ бизнес процесса. К сведению реинжин..., инжиниринг.. и так далее имеют смысл в организациях с большим количеством неформализованных отношений. Здесь это дает большой эффект.., а в производственных структурах, по крайней мере в большинстве это составляет в стоимости конечной продукции 1...5 % от стоимости продукции. Сначала расставьте приоритеты по проблемам, а потом решайте какой способ нужен... By snake on Четверг, Сентябрь 28, 2000 - 14:54: И еще одна мысль: оценка бизнес процесса должна иметь цель - если это информатизация это одно, если повысить эффективность бизнеса это другое. Эти задачи где - то перекликаются. Может и не надо заниматься информатизацией если это ничтожно малая доля в издержках производства.. Во всяком случае прямого доказательства, что в России это дало бешенный эффект я не видел.. Это точка зрения консультанта By Роман Рябой on Четверг, Сентябрь 28, 2000 - 19:45: To snake: 1) Да, цель должна быть. И при этом информатизация не обязательно (т.е. вообще не должна) протеворечить цели повышения эффективности бизнеса, ибо целью информатизации и должно быть повышение эффектвиности бизнеса, а не внедрение каких-то крутых и красивых, но абсолютно не нужных технологий. Именно из-за того, что у многих эти задачи ГДЕ-ТО перекликаются все имеют массу проблем. 2) Очень было бы интересно узнать на чем основан вывод, что "инжиниринг.. и так далее имеют смысл в организациях с большим количеством неформализованных отношений"? Неужели Вам не встречались производственные предприятия, на которых _покупатель_ в течении нескольких или многих часов ходил и собирал подписи для отгрузки продукции? Или где теряются огромные количества (и суммы) сырья/материалов из-за неэффективных бизнес-процессов? Даже приведенная Вами цифра в 5% себестоимости не так уж мала при массовом производстве. В реальной жизни обычно люди вообще не знают _реальных_ цифр по себестоимости. Ну это уже другая история... By snake on Пятница, Сентябрь 29, 2000 - 09:35: Под неформализванными отношениями я понимаю отношения которые не регламетируются ни Гостами, ни технологическим процессом производства... например, торговля в магазине определяется самим хозяином только с точки зрения увеличения прибыли Такие процессы конечно можно и нужно каким то образом упорядочивать.. Но процессы сборки какого оборудования, машин, переработки леса, добычи нефти (формирующие чуть ли не основные статьи издержек) трудно упорядочивать без дополнительных инвестиций и поэтому когда разговор идет о реинж.. или о инжинирин... надо понимать, что это не заканчивается только прописанием процесса как надо, но и дополнительным вливанием денег ... И еще мы забываем, что при четко организованной технологии поточного производства (это имеет очень смутное отношение к технологии Хаммера ...) окружающие бизнес процессы уходят на второй план как по доле в издержках, так и по влиянию их на длительность производственного цикла.. Но они имеют гораздо большую значимость при работе под заказ особенно если заказы мелкие и их много.. И когда я говорил о цифре в 5% я имел больше ввиду не величину этой цифры в абсолюте, а то что у наших фирм, компаний есть больше проблем на настоящем этапе решая которые, вы получаете возможность манипулировать теми составными долями издержек которые гораздо больше 5%.. А эффект Ваших работ, независимо от того кто вы хозяин или консультант, или руководитель крупного департамента будет определяться насколько эффективно Вы сможете снизить издержки.. К таким проблемам и относится то о чем вы сказали никто не знает себестоимости своей продукции, а незнание (и я могу привести много примеров) иногда стоит дороже 5%... By Яковлев Вадим on Среда, Ноябрь 15, 2000 - 10:32: Извините, если вопрос не вписывается в дискуссию. Но я не могу решить для себя как описывать бизнес процессы. Тут было сказано что процессы плоские и неирархические. У нас предприятие связи (городская телефонная сеть). Основные бизнес процессы - это обработка заявок абонентов на выполнение услуг. Исполнителей много. Много условий по дальнейшему маршруту обработки заявки. Есть параллельное выполнение операций. Мне показалось, что это лучше описывать с помощью IDEF3. Недостаток невозможности описания исполнителей менее важен, чем отсутствие описания условий выполнения операций. Хотелось бы получить рекомендации: какой стандарт из 3х- IDEF0, IDEF3, ISO9000 рекомендуется для описания бизнес процессов . By Евгений on Четверг, Ноябрь 16, 2000 - 14:20: Яковлеву Вадиму: Как говорилось выше, определитесь с ЦЕЛЬЮ. Или попытайтесь ответить на вопрос: "Для чего я моделирую бизнес-процессы?" А уже исходя из ответа на него попробуйте выбрать методику описания. Как наиболее приемлимыми считаю IDEF0 & IDEF3 - для анализа предметной области и создания словаря (глоссария) бизнес-системы и набор диаграм UML (Use Case)- для анализа прецендентов и атеров системы, сценариев, ниток и т.д. By Олег Смирнов on Четверг, Ноябрь 16, 2000 - 15:12: Евгений, для описания бизнеса "в крупную клетку", UML ну уж очень сильнодействующее средство, вполне достаточно картинок в Visio (предмет бизнеса, информационная модель и т.д.). Кстати и начинать необходимо с этого, а потом IDEF. By Евгений on Четверг, Ноябрь 16, 2000 - 18:48: Олег, спасибо Вам за совет. UML вполне нормальное средство, все зависит от того для кого Вы пишите модель. Для архитектора ИС или для Заказчика и как у Вас поставлена работа над проектами в компании. В дискуссию впадать на этот счет не имею желания. By Олег Смирнов on Пятница, Ноябрь 17, 2000 - 11:11: Евгений, действительно, если система разрабатывется с нуля, то UML - ради бога, если привыкли, я-же работаю с готовыми системами, где UML излишен. То-есть мы наверное говорили о разных проектах. By Евгений on Пятница, Ноябрь 17, 2000 - 12:14: Олег, видимо так оно и есть. Судя по вопросу Яковлева Вадима у него"предприятие связи (городская телефонная сеть)". А вот для чего и кого он пишет модель не ясно. Но описывать реакцию системы на события и из этого эмитировать состояния системы и ее поведение удобно в UML. А описать бизнес и разобраться в существующем "бардаке" - тут Вы конечно же правы. Вадим так и не уточнил свои ЦЕЛИ. А поэтому мы можем только предполагать, что же ему нужно. Может посоветуете готовую интегрированную систему для телеком-компаний. By Вадим on Вторник, Ноябрь 21, 2000 - 14:14: Извините, что некоторое время не был в форуме. Цель описания бизнеса-как верно подметил Евгений, разобраться в существующем "бардаке". Но возможно необходимо учесть, что происходит это изнутри, т.е. я - работник предприятия. При этом получить хорощую поддержку и финансирование от руководства на эти работы проблематично. Если есть примеры систем для предприятий связи - буду благодарен за информацию. Единственное уточнение - примеры для компаний сотовой связи и подобных не подойдут, поскольку для телефонных компаний необходимо обслуживать и расширять еще обширное линейное хозяйство на фоне большого количества абонентов и услуг. By Аноним on Среда, Январь 17, 2001 - 11:12: Процесс состоит из отдельных операций. Поцесс всегда начинается от клиента. Для выполнения операций должны выполняться определенные функции. Функции невозможно привязать к конкретной операции, однако в свою очередь функции могут быть процессами, которые не выходят на клиента. Приведу пример.Городская телефонная сеть. Последовательность операций по подключению абонента в телефонную сеть-это процесс. Этот процесс не содержит операции по ремонту оборудования АТС. Однако чтобы это(выполнить услугу подключения) возможно было сделать, необходимо поддерживать в рабочем состоянии станционное оборудование, линейное хозяйство, каналы связи. Функцией в данном случае выступает процесс профилактических и ремонтных работ на оборудовании.Эта идеология соответствует стандарту iso9000.Так что же такое бизнес процесс в трактовке стандартов IDEF? И, может, именно в том, что Бизнес процессы описывают любые операции, происходящие на предприятии( процесс не обязательно начинается от клиента), и состоит различие описания ISO & Idef.Ну Вы уж простите, если я не прав. Меня до сих пор мучает вопрос по какому стандарту лучше описывать процессы на предприятии. Как будто получается, что Idef подмножество Iso. Вадим. By Афонин Виктор on Суббота, Январь 20, 2001 - 00:29: Добрый день/вечер, Все очень интересно. Но страшно неудобно читать сообщения в форуме. Нельзя ли как-то размещать их в обратном хронологическом порядке... Извините за офф-топик, но я думаю, что это в интересах всего данного форум-сообщества :) By Garya on Понедельник, Март 12, 2001 - 13:31: С интересом наблюдал за ходом дискуссии. По поводу того, что такое функция, и что такое процесс - высказывались мнения от математической точки зрения до точки зрения едва ли не работника кадровой службы. Меня удивило, что отрицательной реакции на математическую точку зрения не возникло, хотя IMHO она тут не совсем уместна. Хочу заметить, что термины "функция" и "процесс" используется также и в программировании, и эти понятия более близки к рассматриваемому вопросу. У функции могут быть аргументы. Причем, в разряд аргументов могут попасть и временнЫе характеристики.При решении на практике одной задачи я пытался ее рассматривать в таком ракурсе. Выписан счет - на 3 дня забронированы ТМЦ. Это событие, которое изменяет состояние системы. Причем, учетное время простирается до бесконечности в обе стороны и в конкретный момент времени всегда четко определено состояние системы в любой точке по координате времени. Что имеется в данном случае? Счет выписан. Оплата не поступала. Имеется резерв на 3 дня и снятие с резерва после их истечения. Это все появляется в момент выписки счета, включая состояние системы, отображенное на будущее время. Поступит оплата вовремя - состояние системы опять изменится. Из мягкого резерва ТМЦ переводится в жесткий резерв, инициируется операции связанные с отгрузкой (модификация плана отгрузок). Не получена оплата - НИЧЕГО НЕ МЕНЯЕТСЯ. Получена оплата с опозданием - если есть незарезервированные ТМЦ, они резервируются в жесткий резерв, нету - производится предварительное резервирование ТМЦ, отсутствующих на складе, формирование заказа в снабжение, постановка поступившей оплаты на ранее не зарезервированный товар... И в далеком будущем - ТМЦ нет, списана кредиторская задолженность по истечению срока исковой давности... Шокирует? А разве не красиво? Заранее все видно - что будет, если НИЧЕГО БОЛЬШЕ НЕ ПРОИЗОЙДЕТ. Процессов нет, остались одни функции.Могу предложить еще такую трактовку. Функция - это запланированная реакция системы на событие. А процесс - это фактическая реакция системы на событие. Вот и все.Задача проектировщика отработать реакции системы на любое воздействие исходя из всех возможных комбинаций параметров системы, имеющих существенное значение для данного воздействия. By Сергей Рубцов on Четверг, Май 10, 2001 - 13:54: GaryaКак мне показалось, Вы просто описали иделогию управления по событиям.Если это так, то, собственно, так и должны строиться грамотные процедуры управления и с учетом именно этой идеологии "рисоваться" IDEF0-диаграммы.Другими словами, на второй странице IDEF0-модели просто обязан красоваться блок идентификации\обработки событий.Тогда будет абсолютно ясно, что activity есть процесс... Честно, говоря я не понял, почему при обсуждении отличий между процессом и функцией никто не обратился к классикам. Например,1. По Давенпорту-Шорту бизнес-процесс определяется как «набор логически взаимосвязанных действий, выполняемых для достижения определенного выхода бизнес-деятельности»2.По Демингу: «Слюбые виды деятельности, встречающиеся в работе организации, мы должны рассматривать как процесс»3. По Верникову: «Процесс - это горизонтальная иерархия внутренних и зависимых между собой функциональных действий, конечной целью которых является выпуск продукции или отдельных ее компонентов»4. По Зиндеру: «Процессы - это логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как Продукт или Услуга»5. По ТForum «Систематическое, последовательное выполнение функциональных операций, которые приносят специфический результат» Мне кажется, что мировая общественность уже пришла давно к единому мнению, что такое процессы в организациях.Альтернативное понятие процесса можно получить только двигаясь от Винера и Колмогорова. Кому это нужно? By Евгений on Четверг, Май 10, 2001 - 14:34: >"Функция - это запланированная реакция системы на событие", "...у функции могут быть аргументы...".У меня тоже есть аргументы, математические: Комогоров и Фомин, "Функциональный анализ" Наука, М.: 1976 - "функция есть отображение нормированного пространства на числовую ось". [1][2][3][4][5][6][7][8][9] следующая>> [вид для печати] Рег. номер Эл 77-2071. © CONSULTING.RU, 2011.Воспроизведение (целиком или частями) материалов сервера может производитьсятолько по письменному разрешению правообладателей. Re-engineering & support by consulting.ru, 2003