"Универсальные" методологии

В данном разделе рассмотрено семейство "универсальных" методологий, часто используемых в самых различных отраслях бизнеса и организации бизнес-процессов.

"Обычное" предприятие имеет тысячи, если не десятки тысяч наименований складской номенклатуры. Отслеживать движение (или например, изменение стоимости) всех наименований товаров с "одинаковой" тщательностью практически невозможно. Как уменьшить требуемый "контрольный пул" ? Одной из наиболее часто используемых методик является методика АВС, которая подразумевает классификацию материалов на три группы: А, В, С, которые отличаются например, по интенсивности движения, или, например, по вкладу в окончательную стоимость готового продукта. Соответственно, ежедневно отслеживается движение по складу (изменение стоимости) товаров первой группы, еженедельно - второй, и наконец, ежемесячно - третьей. Поскольку статистически доля товаров первой группы как правило невелика, то существенно уменьшаются трудозатраты на управление товародвижением. Данная методика имеет достаточно универсальный характер и в последнее время приобретает характер идеологии. Определенную трудность представляет выбор критерия классификации продукции (товаров, материалов) по группам, соответствующий сущности решаемой проблемы. Однако при наличии исторических данных о движении товаров и автоматизированной системы управления данная задача может быть решена весьма эффективно.

Семейство методологий создавалось в то время, когда существовала "иллюзия всеобщего математического моделирования", в соответствии с чем предполагалась следующая последовательность действий: определение функциональной (концептуальной) модели бизнеса - определение данных, необходимых для реализации модели - математическое моделирование - оценка результатов - реорганизация модели - и новая итерация, пока модель не будет "поставлена в рамки". В соответствии с этой концепцией и предполагалось создать серию стандартов:

• IDEF 0

Стандарт функционального моделирования (принят)

• IDEF 1 (X)

Стандарт информационного моделирования (принят), хорошо известен еще и под названием "ER- диаграммы".

• IDEF 2

Стандарт математического моделирования (не принят). Не принятие стандарта математического моделирования было вполне естественным, так как при реализации математической модели приходилось либо жертвовать ее точностью, либо ... самой возможностью что-то моделировать, ввиду чего никогда нельзя было с полной уверенностью говорить о "соответствии математической модели функциональной", разработанной в стандарте IDEF 0. Тем не менее существуют программные продукты которые позволяют проводить математическое моделирование по функциональному описанию в стандарте IDEF 0.

• IDEF 3

Наиболее важный из серии современных стандартов, определяет методологию моделирования процессов (то есть проще говоря, построения технологических карт). Отсутствие методологии моделирования процессов(технологий) было существенным недостатком семейства методологий IDEF, что затрудняло использование их, например, в проектировании корпоративных информационных систем.

В последние годы семейство методологий IDEF получило дальнейшее распространение, став полноценной системой разработки систем управления, от концепции проекта до создания кода программного продукта, выполняющего определенные на концептуальном уровне задачи. В настоящем разделе будут кратко рассмотрены наиболее интересные компоненты современного развития семейства IDEF.

• DFD "Data flow diagram", "диаграммы потоков данных"

Широко распространенная методология моделирования процессо-ориентированного типа.

• "Моделирование в терминах системы"

Одной из существенных проблем при использовании "универсальных" методологий моделирования является дальнейшее использование результатов в практической работе, например при внедрении или создании корпоративной информационной системы. Часто оказывается (особенно до создания методологии IDEF 3), что применить результаты длительной работы достаточно сложно. Поэтому неудивительно, что все крупнейшие поставщики интегрированных программных систем озаботились созданием специализированных систем моделирования, адекватных применяемой системе. Наиболее интересная методология "моделирования в терминах системы" создана усилиями специалистов BAAN.

Собственно, понятие БПР имеет вполне четкую дату рождения и вполне определенных родителей. Но вот определения оно фактически не имеет. М.Хаммер и Дж.Чампи в своей классической работе говорят о реинжиниринге: "фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных актуальных показателях их деятельности: стоимость, качество, услуги и темпы" (цитировано по: Реинжиниринг бизнес-процессов и информационные технологии, Э.Попов, М.Шапот, Открытые системы, # 1(15)/96 ╥ стр. 62-69). Данное определение допускает безграничное множество толкований, особенно, если не читать саму книгу, в которой оно приведено. Для правильного понимания причин появления и сущности понятия необходимо определить исторический и бизнес контекст, в котором оно возникло. Прежде всего нужно понимать, что характерное "время жизни" принятой (и как правило замороженной в информационно - прикладной инфраструктуре) бизнес-практики компании составляет не менее 10 лет. Естественно, что за такое время существенно меняется бизнес-окружение, технологии (в том числе информационные) и т.п.. . Приходит время, и становится ясно, что нужно что-то менять. А ведь в крупной компании в корпоративной системе задействованы тысячи, а то и десятки тысяч человек. Ой как непросто провести изменения. Поэтому рождается мысль "эволюционных изменений". Но управление эволюционным проектом такого масштаба - процесс не менее сложный, чем революция. Не проще ли встать под знамена революционных преобразований - то есть БПР. Но как учил великий Ленин (помните !) - сначала надо хорошо подготовиться и выбрать вождя. А если план окажется неверным ...., или вождь вдруг сбежит.... . Таким образом БПР - это скорее идеология, нежели разработанная методология. Однако она нашла живой отклик в среде поставщиков различного рода программных пакетов, так как давала удобную и модную рекламную затравку. И неважно, что пакет, и методика на которой он основан, пригодны как для революции, так и для эволюции, да может и вообще не имеют к ним прямого отношения. Главное - покупают. Справедливости надо сказать что существует и боле тесная связь БПР и прикладного ПО, а именно то, что собственно, программно-прикладная система, или как сейчас принято говорить, обобщая, КИС, служит как важный инструмент "консервации" заложенной в ней методологии. Даже если пытаться эволюционировать вместе с одним, постоянным, поставщиком, что не всегда удается, то все равно легко скатиться в ситуацию "и вечный бой, покой нам только сниться". Естественно, долго в такой ситуации реальный бизнес-обьект ( то есть предприятие) существовать не сможет.

В России ситуация осложняется и одновременно упрощается тем, что практически мало кто отрицает необходимость революционных изменений в практике управления, ввиду чего термин БПР лег на очень "удобренную" почву. Другое дело, что, в отличие от Запада, часто в конкретной компании нет, а порой даже и не искали, не только проторенного пути, но и вешек, чтобы переходить бурные реки бизнеса вброд. В соответствии с рекламными обещаниями ставка делается на программные продукты: "вместе с нами Вы сделаете рывок в организации Вашего бизнеса". Правда рекламодатели забывают сказать, что предоставляю только строительный материал, а как проектировать и тем более мостить дорогу к светлому будущему - это уже личное дело заказчика. Сейчас стало еще хитрее. Теперь говорят: "наша методология внедрения и наши специалисты помогут Вам эффективно использовать наше программное обеспечение и быстро достичь результатов от внедрения", правда забывают добавить - если Вы знаете, как хотите его использовать и что хотите получить в итоге.

Прежде всего необходимо сказать, что все же БПР и внедрение АСУ есть процессы совершенно различные, и ни в коем случае их не следует смешивать. Более того большинство неудач при внедрении АСУ связаны именно с тем, что перед началом проекта не было четко уяснена его цель, точнее по умолчанию предполагалось, что "создать систему управления" - значит внедрить нечто компьютерное. И в результате - неудача.

В действительности внедрение компьютерной системы, особенно западной системы в России, приводит к необходимости проведения некоторой модификации бизнес-процессов, которая в первом приближении может быть названа бизнес-процесс реинжинирингом, хотя сущность данного процесса все же другая. То есть как бы система управления первична, а ее реализация в виде компьютерной системы вторична. Кажется очевидно !

Как показывает практика - в России совершенно не очевидно. Впрочем также ясно и почему - гораздо легче сказать - давайте внедрять современную систему финансово-экономического управления (в уме - систему управления как таковую, пишем - компьютерную программу), нежели признаться - "Господа! У нас твориться черт знает что ! Давайте разгребем этот бардак!" Хорошо хоть если где-нибудь на заднем плане данное желание присутствует. Гораздо хуже (и гораздо чаще) - реальные запросы никем не сознаются и тем более не формулируются.

Часто возникает вопрос - с чего начать внедрение системы управления ? Ответ на этот вопрос конечно зависит от предполагаемого конечного результата, но каков самый простой вариант?. Или вы хотели бы убедиться, что существующая система "удовлетворяет международным стандартам". Как это сделать ?. Мы предлагаем попытаться внедрить систему управленческой отчетности. Что она собой представляет, будет рассказано в этой главе.

Для эффективного управления проектом создания корпоративной системы финансово-экономического управления необходимо преобразовать проект в последовательность действий, имеющих четко определенные цели, ограниченных во времени и допускающих независимые процедуры верификации. Все элементы проекта должны быть документированы и утверждены соответствующими структурами управления. Естественно необходим подготовленный персонал, причем особенно большое значение имеет личность руководителя проекта.