Тезисы лекций для выполнения контрольной работы №1 по дисциплине «ERP-системы» для магистров направления подготовки 240700 «ИС и технологии» (стр. 1 )

Тезисы лекций для выполнения контрольной работы №1

по дисциплине «ERP-системы»

для магистров направления подготовки 240700 «ИС и технологии»

ПЛАН

Тезисы лекции №1. Реинжиниринг бизнес-процессов…………………………………….1с.

Тезисы лекции №2 ERP-система и примеры бизнес-приложений ERP-систем……….12с.

Тезисы лекции №3 Мировой рынок ERP-систем……………………………………………………16с.

Тезисы лекции №4 Критерии выбора  ERP-систем  для России…………………………23с.

Тезисы лекции №5. Характеристики MRP систем…………………………………………26с.

Тезисы лекции №1. Реинжиниринг бизнес-процессов.

1.  Понятие реинжиниринга. Как научно-практическое направление, реинжиниринг бизнес-процессов впервые появился в США и за несколько лет превратился в одну из ведущих и активно развивающихся отраслей информатики. Сегодня начинается продвижение консалтинговых услуг и инструментариев по реинжинирингу и на российский рынок. Отечественная практика применения реинжиниринга показала, что этот метод необходим, особенно в условиях проведения глобальной экономической реформы и активного внедрения России в мировую экономическую систему.

Впервые термин "реинжиниринг бизнес-процессов" (от англ. business process reengineering, BPR) был введен М. Хаммером, который определяет этот вид деятельности как "фундаментальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных актуальным показателях их деятельности: стоимость, качество, услуги и темпы".

В западном мире (и, в первую очередь, в США) реинжиниринг приобретает все большую и большую популярность. Чтобы проиллюстрировать эту тенденцию, приведем несколько цифр.

Компании США затратили на проекты по реинжинирингу бизнес-процессов в 1994 году около 37 млрд. долларов. В течение ближайших лет рост затрат на решение этих задач ожидается на уровне 19% в год.

По данным компании Emst & Young, 100 крупнейших банков Северной Америки затратили в 1999 году около 3,9 млрд. долларов только на реинжиниринг своих подразделений. За последние полтора года правительство США инициировало более 250 проектов по реинжинирингу, а сегодняшний рынок инструментальных средств поддержки BPR оценивается более чем в 100 млн. долларов и растет со скоростью около 60% в год.

По результатам опроса, проведенного Emst & Young среди финансовых директоров 80-ти крупнейших компаний США, основной мотивацией проведения реинжиниринга было улучшение сервиса и качества продукции (услуг), а также снижение расходов.

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

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

Одной из основных особенностей BPR является ориентация реинжиниринга не на функции, а на процессы. Причем из всех концепций менеджмента, основанных на процессах, BPR рассматривается как наиболее эффективная, революционность которой обусловлена современным состоянием информационных технологий.

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

Поскольку BPR оперирует с такими понятиями, как бизнес-процесс, бизнес-система, деловая процедура, то в целях более четкого восприятия этих терминов следует дать следующие определения.

Бизнес-система - это связанное множество бизнес-процессов, конечной целью которой является выпуск продукции. Под продукцией, понимают товары, услуги и документы.

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

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

Основными показателями оценки эффективности бизнес-процессов являются:

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

Перечислим базовые принципы, положенные в основу реинжиниринга бизнес-процессов:

·  несколько рабочих процедур объединяются в одну, т. е. происходит горизонтальное сжатие процесса (по имеющимся оценкам, горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз);

·  исполнители принимают самостоятельные решения, т. е. осуществляется не только горизонтальное, но и вертикальное сжатие процессов (наделение сотрудников большими полномочиями и увеличение роли каждого из них приводит к значительному повышению их отдачи);

·  шаги процесса выполняются в естественном порядке;

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

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

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

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

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

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

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

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

Таким образом, использование бизнес-инжиниринга начинается с того, что руководители, которые хотят взять его на вооружение, должны перестроить свое сознание. А менять устоявшиеся убеждения - ой, как сложно! Это могут сделать менеджеры инновационного типа, которые постоянно находятся в поисках нового и осмыслении этого нового для совершенствования управления своим предприятием.

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

Пример. Реинжиниринг: бизнес-процессы или зоны ответственности? , *****@***ru http://consult. *****

Лет 8 назад консалтинг был относительно прост. Почти на любом предприятии изменение 2-х - 3-х главных функций в управлении давало чуть ли не стопроцентный прирост эффективности. Несколько лет после кризиса требовали уже более скрупулезной работы. Чтобы получить аналогичные результаты, стало необходимым отладить множество процедур, большинство из которых выполнялось, в принципе, правильно, но могло быть оптимизировано. Последние же годы вновь начинают напоминать докризисную эпоху. Хотя 80% проектов связано преимущественно с быстрым ростом компаний, оставшаяся часть направлена на ликвидацию последствий неудачного реинжиниринга бизнес-процессов, и требует кардинальных мер.

Оставляя в стороне вопрос возможной некомпетентности или неподготовленности людей, проводящих реинжиниринг, попробуем разобраться в самом предмете.

На рисунке показано деление предприятия по функциональным отделам, каждый из которых возглавляет руководитель (А, Б, и т. д.). Пунктиром отмечены процессы, которые имеют простую конфигурацию (процесс 1), смыкаются (процессы 2 и 3), разветвляются (процесс 4). В их реализации необязательно задействованы все отделы фирмы или в одной и той же последовательности.

Идеи, поставленные во главу угла сторонниками данного подхода, примерно следующие:

1. Реинжиниринг бизнес-процессов позволяет организовать фирму или бизнес кардинально по-новому и наиболее оптимальным образом («революционное преобразование» по Хаммеру).

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

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

Под всеми тремя идеями можно подписываться не глядя. Но …

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

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

3. Бизнес-процессы необходимо автоматизировать, именно в их логике удобно ставить задачи программистам, но стоит ли удобство программирования объявлять первым приоритетом для предприятия?

В «сухом остатке» идей реинжиниринга бизнес-процессов имеется одна относительно прогрессивная идея, впрочем, актуальная еще с 70-х годов, – это автоматизация предприятия. И одна важная идея отсутствует – причина, по которой бизнес-процессы могли бы работать. Их можно красиво нарисовать и даже жестко внедрить почти в задуманном виде, но ведь нас, кажется, интересовал динамичный результат?

Динамику создают люди, принимая решения в изменившейся ситуации – внедряя и корректируя процессы по мере необходимости. Без людей любая управленческая схема нежизнеспособна. И методисты реинжиниринга предлагают решение данной проблемы: вводом «хозяина» бизнес-процесса, управляющего его течением.

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

Почему это не работает, тоже понятно. Руководители отделов, освобожденные от ответственности за результат, благополучно занимаются «футболом», посылая «хозяина» процесса вместо себя договариваться со смежниками. А «хозяин», не имея возможности заставить работать не подчиняющихся ему руководителей, либо спускает все на тормозах, либо привлекает для решения вопроса директора предприятия. (Последний и оказывается в матричной структуре единственным реально ответственным).

В проектных организациях, консалтинговых и рекламных фирмах матричная структура может быть эффективна. Эффективность достигается сохранением принципа единоначалия. Если всю власть (в т. ч. право распоряжаться бюджетом) по проекту отдать «хозяину», если все функциональные отделы в рамках установленных процедур и в заранее оговоренные сроки будут обязаны выполнять его заказы, то цели проекта будут достигнуты. Бизнес-процесс эффективно реализуется.

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

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

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

Строго говоря, в функциональной структуре тоже можно провести реинжиниринг любой детализации и даже назначить «хозяев процессов» наряду с имеющимися начальниками отделов. Чтобы заставить работать такого монстра, необходимо сохранить принцип единоначалия и четко расписать зоны ответственности, полномочия и процедуры взаимодействия для каждого руководителя отдела, хозяина процесса и каждого стыка матрицы. Тогда эффективность структуры упадет не так низко, как это происходит на большинстве фирм.

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

В общем виде алгоритм реинжиниринга предприятия может быть следующим:

·Вначале оцениваются сильные и слабые стороны предприятия – его потенциал (который составляют, в первую очередь, идеи и люди, опыт и квалификация). По наиболее интересным для фирмы направлениям оцениваются потенциальные и реальные рынки.

· Затем для перспективных рынков выстраиваются альтернативы позиционирования (возможность стать розничной сетью, крупным оптовиком, производителем, законодателем мод, и т. д.). Выбираются наиболее приемлемые альтернативы и согласовываются между собой.

· Затем формулируются общие стратегические цели предприятия (которые могут охватывать разные рынки и отрасли) и цели бизнесов.

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

· Когда стратегии определены, прорабатываются мероприятия по их реализации, оптимальным образом выстраивается оргструктура (включая все технологии взаимодействия подразделений, бизнес-процессы, а также системы планирования, стимулирования и контроля).

· Затем по каждому бизнесу формируются бюджеты, сводятся в общий, проводится коррекция запланированных мероприятий, и выстраивается годовой оперативный план. Реализация плана тщательно контролируется.

Бизнес-процессы корректируются (или выстраиваются совершенно по-новому) на стадии разработки структуры, когда становится ясным ее стратегическое предназначение. Степень «революционности» преобразований определяется принятыми стратегиями. А работоспособность бизнес-процессов обеспечивается, как это ни парадоксально, отсутствием у них «хозяев».

Такое «крамольное» заявление необходимо поддержать аргументацией, поэтому рассмотрим сначала случай, когда «хозяин» у бизнес-процесса есть. И, допустим, фирма настолько проникнута «правильным» корпоративным духом, что, несмотря на многоначалие, вовремя и качественно делает свое дело. Тогда работа типичного менеджера по продукту выглядит примерно так:

Он организует исследования рынка и определяет, каким образом должен развиваться продукт.

Он формулирует задание дизайнерам на разработку внешнего вида продукта, конструкторам – на его потребительские качества, технологам – на состав, экологичность, себестоимость продукта.

Он определяет для производства объем и график выпуска продукта.

Вместе с рекламистами и маркетологами разрабатывает программу продвижения продукта (не забыв согласовать ее с коллегами по другим продуктам ассортимента).

Он разрабатывает сбытовикам план по сбыту, и логистикам – план поставки продукта в точки реализации.

Он…

Абсурд? У него не хватит квалификации, чтобы делать всю работу за всех? Тогда что же он может делать? Похоже, только следить за своевременным и качественным выполнением обязанностей функциональными подразделениями предприятия. Причем и здесь он вынужден полагаться на заключения специалистов, и если технолог утверждает, что сковородки можно делать исключительно из титана, с ним приходится соглашаться. (Начальник дивизиона в этой ситуации поискал бы другого технолога).

Бизнес процессы современного предприятия слишком сложны, чтобы один «хозяин» мог охватить их полностью. А поскольку его задача сводится к координации действий функциональных подразделений, то почти всегда ее эффективнее решать другим способом, без участия «хозяина»

Что теоретически достигается вводом данной фигуры?

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

Контроль, осуществляемый заинтересованным лицом.

Инициация разработки или изменения бизнес-процесса, переставшего решать полезные задачи.

На практике, предприятию более выгодна совокупная результативность бизнес-процессов, которые тесно связаны между собой. (И если бы мы плодили «горизонтальных хозяев», кто-то должен был озаботиться налаживанием связей между ними). Задача общей результативности отчасти решается определением целей компании и доведением их до каждого менеджера. Отчасти – вводом системы стимулирования, поощряющей достижение общефирменных целей (в заработной плате всех сотрудников имеется весомая составляющая, привязанная к результатам фирмы в целом). Отчасти – правильным распределением зон ответственности функциональных подразделений: в эти зоны обязательно должны входить процедуры взаимодействия со смежниками.

Тогда на стыках отделов проявляются не полностью совпадающие интересы смежных структур, в увязке которых эти структуры весьма заинтересованы. Результатом увязки становится работоспособный компромисс – процедуры взаимодействия, устраивающие обе стороны до тех пор, пока способствуют достижению общего результата, и пока четко соблюдаются. Нарушение сроков или качества в передаче продукта (товара, информации, услуги) от подразделения к подразделению сдвигает баланс интересов, поэтому сразу становится предметом разбирательства, инициируемого «ущемленным» отделом. То есть, как сам бизнес-процесс реализуется разными функциональными подразделениями, так и контроль за его качественным выполнением является распределенной функцией, осуществляемой подразделениями по зонам ответственности.

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

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

Подразделение-заказчик принимает результаты бизнес-процесса и отвечает за их эффективное использование. Структуры-исполнители отрабатывают свои части согласно установленным процедурам.

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

Что же касается автоматизации и перевода компании на «рельсы прогресса», то для этой цели как раз и желателен хозяин процесса, чьей главной задачей будет перевод запросов руководителей функциональных подразделений на язык постановки задач программирования. Только реинжиниринг предприятия должен быть выполнен до того.

2. Как добиться успеха в безнадежных проектах

Константин Берлинский, *****@***com системный аналитик Департамента информационных технологий при Правительстве Республики Молдова (Кишинев)
Впервые опубликовано в журнале "Открытые системы" №10 2002

Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули "забирают" все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.

Все это признаки типичного безнадежного проекта [1]. Интерес к способам решения проблем, возникающих в процессе разработки проектов, не ослабевает. Основной методологией разработки в нашей организации является Rational Unified Process (RUP), поэтому представленные в статье решения ориентированы на продукты компании Rational Software. Однако тех же результатов можно достичь, используя аналогичные инструменты.

Основные черты безнадежных проектов изложены в [2]; там же рассказывается, что делает их таковыми и как их распознать еще до принятия стратегических решений. Напомним факторы, которые переводят проекты в разряд безнадежных:

административные проблемы: хаотичный процесс разработки; много политики; устаревшие практики и стандарты; чрезмерный оптимизм; "непрозрачность" работ для заказчика; постоянно изменяющиеся требования; затрудненные коммуникации; слабая мотивация сотрудников; проблемы проектирования: концептуальная неполнота и противоречивость; отсутствие единой терминологии; недостаточная инкапсулированность модулей; проблемы разработки: повторное изобретение колеса; игнорирование требования удобства использования; проблемы с документацией; плохо налаженное тестирование.

Информационную систему крайне трудно разрабатывать без четкой методологии. В своих проектах мы используем адаптированную под наши нужды технику RUP. При этом артефакт Business Vision становится Концепцией Системы, документом на 5-10 страниц, описывающим основные архитектурные моменты информационной системы. Business Use Case Model в нашем понимании становится Техническим Заданием (ТЗ), документом, который согласовывается с заказчиком и описывает информационную систему с его точки зрения. Составные части ТЗ: бизнес-процесс, организационная структура предприятия, состав документов, технология проекта, различные поясняющие диаграммы (схема движения информации, основные потоки работ и т. п.). Далее, мы выделяем Технический Проект (Analysis Model), в котором описывается вид на систему с точки зрения программистов: структура выходных форм; список запросов и таблицы базы данных; внешние интерфейсы; доступные модулям процедуры сервера приложений и перечень функций каждого модуля.

На рис. 1 отображено распределение ролей в проекте. Системный аналитик пишет ТЗ и согласовывает его с заказчиком, проектировщик делает ТП и ставит задачи программистам. Реализованная информационная система тестируется отделом контроля качества совместно с программистами и представителями заказчика; в случае успеха отдел тиражирования занимается внедрением программного обеспечения.

Рис. 1. Методология разработки проектов

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

Не менее острой проблемой является наличие в организации устаревших практик и стандартов. Если коммерческим компаниям с этим, как правило, удается справиться, то в государственных учреждениях стандарты оформления документов, документооборот и разработка значительно бюрократизированы. Действенным решением служит коренная модернизация отделов стандартов качества и технической документации, внедрение новых стандартов и технологий (ISO, CMM, RUP и т. д.), а также написание собственных методик.

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

Главной причиной недовольства заказчика обычно является непрозрачность процесса разработки. Заказчик выдвигает требования к информационной системе, объясняет бизнес-правила, а системный аналитик, общаясь с ним, разрабатывает ТЗ. Однако "на выходе" система часто не вполне соответствует исходным запросам, особенно в случае изменения условий бизнеса. Поэтому важно сделать заказчика частью команды. В этом смысле очень привлекательна методология экстремального программирования, одним из постулатов которой является присутствие заказчика "в одной комнате с программистами". Заказчик объясняет user story (ключевые функции информационной системы), и ее реализуют за строго определенное время.

К сожалению, "идеальных" заказчиков мало и проблемы прозрачности и изменяющихся требований приходится решать иными методами. Для наглядности информации в ТЗ мы применяем графические стереотипы основных терминов и понятий системы; до написания кода приложений согласуем формы интерфейса, а текущая бизнес-модель, автоматически сформированная модулем WebPublisher из Rational Suite, всегда доступна для просмотра в формате HTML. В случае изменения бизнес-требований заказчик сообщает об этом системному аналитику, и тот исправляет модель информационной системы. Проектировщик определяет масштабы изменения и отражает их в ТП, а затем передает новую постановку задач программистам (рис. 2).

Проблемы изменения требований оказывают еще более негативное влияние на проект в случаях, когда затруднены коммуникации - как между заказчиком и командой, так и внутри нее. Наш заказчик "распылен" (деятельность нашей организации связана с автоматизацией госструктур и построением единых регистров населения, транспорта, правовых единиц и т. п.), поэтому основными средствами взаимодействия становятся совещания и рабочая документация проекта. Чтобы совещание было успешным, следует учесть ряд моментов. Тему совещания надо четко определить, подготовив список конкретных вопросов; приглашаются только нужные люди с полномочиями принятия решений; оптимальное число участников - 4-7 человек; по каждой проблеме нужно достичь хотя бы временного, "промежуточного" решения.