Введение в комплексные системы класса ERP. Классификация систем обеспечения управленческого учета

АНО ВПО «Региональный финансово-экономический институт» УПРАВЛЕНЧЕСКИЙ УЧЕТ (Третья лекция) ___________________________ http://elearning.rfei.ru СОДЕРЖАНИЕ РАЗДЕЛ 1. ТЕХНОЛОГИЧЕСКАЯ ПОДДЕРЖКА УПРАВЛЕНЧЕСКОГО УЧЕТА.........................................................3 Глава 1.1. Введение в комплексные системы класса ERP ..........3 Глава 1.2. Классификация систем обеспечения управленческого учета..................................................................25 Глава 1.3. Подходы к выбору программного приложения........31 Глава 1.4. Выбор поставщика услуг по внедрению приложения...........................................................55 Глава 1.5. Как подготовиться к внедрению системы.................63 Глава 1.6. Методология внедрения.............................................. 71 2 2 РАЗДЕЛ 1. ТЕХНОЛОГИЧЕСКАЯ ПОДДЕРЖКА УПРАВЛЕНЧЕСКОГО УЧЕТА Глава 1.1. Введение в комплексные системы класса ERP На сегодняшний день автоматизация управленческого учета прочно ассоциируется с компьютерными приложениями класса ERP (Enterprise Resource Planning — планирование ресурсов предприятия). Это очень мощные, функционально богатые продукты, охватывающие практически весь спектр деятельности типового современного предприятия. Вот минимальный перечень подсистем (первый уровень списка) и модулей (второй уровень) типовой ERP-системы: 1. Финансы: • Работа с главной книгой. • Расчеты с заказчиками. • Расчеты с поставщиками. • Кассовые и банковские операции. 2. Логистика: • Отгрузки. • Поставки. • Запасы. • Дистрибьюторы. • Цепочки поставок. 3. CRM: • Продажи. • Обслуживание клиентов. • Маркетинг. 4. Производство: • Производственные мощности. • Планирование. • Производственные заказы. • Цеховое управление. 3 3 5. • • • • Кадры: Кадры. Зарплата. Карьера. Обучение и развитие персонала. Каждый модуль содержит как минимум три основные группы функций: 1. Справочники. 2. Формы ввода. 3. Отчеты. Эти три функциональные группы отражают последовательность работы с модулем: сначала ведутся операции со справочниками, затем осуществляется ввод данных в систему, и на их основе формируются отчеты. Главное требование к современным системам — понятность и простота в использовании. В частности, необходим режим «настройка по мере ввода», когда пустые графы документа в системе заполняются постепенно. Например, вы вносите счет к оплате, полученный от одного из ваших поставщиков. Если не хватает данных о поставщике, можно сразу же зайти в соответствующий справочник и заполнить недостающие параметры. Если не хватает какого-то товара, заводим его в справочнике товаров. При всей своей сложности технология сохраняет главное качество — клиентоориентированность. Разработка справочников. Несколько советов Сегодня намечается тенденция, когда разработка справочников в процессе автоматизации УУ выносится в отдельный проект, потому что любое предприятие — это «зоопарк справочников». Бухгалтерию интересует группировка материалов в соответствии с ПБУ, им нужна минимальная аналитика товаров. Кладовщику нужна классификация в разрезе физических характеристик товарно-материальных ценностей: размеры, местонахождение на складе и прочее. Закупщику 4 4 требуется распределение по категориям, цене, реализуемости и т. д. Каждый стремится создать собственную классификацию. И в условиях разрозненности или отсутствия систем это удается. У каждого классификатора есть своя цель. За что бы вы ни брались, первоначально необходимо сформулировать цель, особенно если речь идет о коллективе: в обществе умных и активных людей легко попасть впросак, ведь любая долгосрочная задача трансформируется в ходе ее выполнения. После формирования цели нужно выделить аналитические признаки будущей классификации. Если цель — структурировать все изделия согласно их принадлежности к группе активов, следует эти группы активов расписать. Известны случаи, когда в качестве справочника берется «Товарная номенклатура внешнеэкономической деятельности» (ТН ВЭД). В ней расписаны почти все вещи, которые существуют в природе. Предназначение ТН ВЭД — быстро и эффективно классифицировать увиденный товар. Безусловно, у нее есть свои недостатки — номенклатуру создавали отнюдь не в целях управленческого учета. В качестве основы для справочника можно взять существующие в вашей компании классификаторы, которые ведут закупщики и кладовщики. Порой их нужно лишь дополнить. Если говорить об автоматизации процесса ввода информации в справочники, лучше воспользоваться системой, которая обеспечивает помощь в создании справочников. Самый простой принцип — электронное анкетирование. Вы входите в систему и выбираете позицию «Завести новый товар». При этом не попадаете сразу в карточку товара с десятком полей (рис. 3.1). Предварительно система просит вас охарактеризовать его: — Речь идет о материальном активе или нет? — спрашивает система. — Материальный актив, — выбираете вы. — Это основное средство или малоценное и быстроизнашивающееся? — Малоценное. 5 5 Рис. 1.1. Ввод информации в справочник Идеальная система не просто верит вашим ответам, но еще и перепроверяет: «Какова стоимость этого предмета?» И если вы ответите, что она превышает, например, 10 000 руб., система вас поправит — в этом случае предмет будет относиться к основным средствам. Системы, построенные по принципу «вопрос-ответ», часто называют экспертными. Ими пользуются телефонные службы медицинской помощи «911», их применяют для технической диагностики самолетов и прочих технически сложных устройств. Главная цель таких компьютерных программ — систематизировать знания о сложных объектах или способах реагирования на те или иные ситуации и помочь человеку быстро, а главное — безошибочно сориентироваться в этих знаниях. Преимущество использования такого подхода в ERP6 6 системах очевидно. Во-первых, вы можете сразу вносить свои классификации и корректировать их по мере ввода. Во-вторых, отвечая на вопросы, вы себя перепроверяете (правильно ли выстраивается аналитика?). Кроме того, весь комплекс сценариев «вопрос-ответ» пригодится в будущем тем, кто станет заводить новые товары. И все же в вопросно-ответной системе без достаточного объема информации легко запутаться. Есть старый проверенный механизм классификации путем «маскирования»: справочник делится на сегменты; каждый сегмент соответствует определенному аналитическому признаку; заводя элемент, вы выбираете из возможных вариантов. Самый трудный момент — эксплуатация справочников. Зачастую даже при использовании сценариев «вопрос-ответ» могут возникать дублирующие друг друга элементы. Например, ваш сотрудник получил партию канатов. В справочнике системы канаты уже заведены. Все совпадает, кроме единицы измерения: в системе — метры, а полученная партия измеряется в катушках. Сотрудник заводит новую карточку изделия — канаты с единицей измерения «катушки», потому что ему так удобнее. Естественно, такие изменения непозволительны, их надо отслеживать. Чтобы свести дублирующие записи к минимуму, необходимо четко прописывать права администрирования. В идеале за изменение справочника отвечает один человек, пресекая все попытки «клонирования». На практике самый верный подход к заведению нового элемента справочника — реализация последовательного бизнес-процесса, в ходе которого аналитические признаки нового элемента присваивает специалист, который является заказчиком данного аналитического признака. Поясним это на примере ведения справочника товаров. Заведение новой товарной единицы Режим обучения во время ввода, о котором рассказывалось выше, относится к моменту первичной работы в системе, предназначенного для того, чтобы люди научились работать в 7 7 системе. «Настройка по мере ввода» хороша только для обучения, потому что обычный пользователь, отвечающий, скажем, за ввод счетов к оплате, не обладает достаточной квалификацией для заведения новой номенклатурной единицы, нового счета в плане счетов, банковских реквизитов и т. п. Во время эксплуатации все обязанности должны быть четко распределены. Сотрудники на местах не могут вносить новые категории в справочник, не обладая всей полнотой картины. Вводить категории и товары должен администратор справочника, которому при необходимости присылают заявки на новые элементы. Согласно им он и работает. Сам процесс заведения нового номенклатурного наименования также лучше регламентировать, поскольку в крупных фирмах зачастую нет либо дорого держать человека, который «знает все». Первичные признаки, которые необходимы для создания новой товарной позиции, лежат в области товароведения. Первым вопрос решает товаровед. Он классифицирует товары по основным группам и передает их для детальной классификации категорийному менеджеру. Разные группы товаров ведут разные менеджеры: один хорошо разбирается в алкоголе, другой — в продуктах быстрого питания и т.д. Карточка нового товара «ходит» по цепочке ответственных и постепенно дополняется. Недопустима ситуация, когда товар заводится в момент его прибытия на склад: как брать на баланс то, что не ожидали получить? Если товар прибыл на склад, значит, его предварительно заказали. Следовательно, и классифицировать его надо как минимум на стадии заказа. Проблем возникнуть не должно. Если товар заказали, значит, у предприятия есть соответствующий вид деятельности. Если есть вид деятельности, значит, он фигурировал в бизнес-плане, и под него были заведены плановые статьи дохода, то есть продумана финансовая классификация изделия. Конечно, надо быть готовым к тому, что классификатор — живой организм. Вы будете ошибаться и не раз его переделывать. А это влечет за собой корректировку операции задним числом. 8 8 Отсюда вытекает требование к компьютерной системе: она должна обеспечивать преемственность изменений классификации. Финансовая структура — тоже классификатор. Перечень центров затрат, доходов, их иерархическая подчиненность друг другу — такой же живой организм, который постоянно меняется. Вы должны быть уверены, что ваш отчет за прошлый год будет отражать финансовую структуру за прошлый год, и система не пытается отобразить прошлогодние данные в разрезе сегодняшней финансовой структуры. Эти требования очевидны, но в очевидности кроется опасность ошибок: можно потратить деньги и долго внедрять систему, которая не позволяет выполнить элементарные действия. При формировании справочника возникает вопрос: как классифицировать — как есть или как должно быть? Ответ кроется в примере, когда вы на момент принятия товара уже сформировали соответствующую деятельность: финансовую часть и группы, классифицирующие аспекты. Так и в бизнесе: вы планируете политику, бизнес-деятельность, связанные с ней затраты; соответственно есть классификация этих затрат. В справочники вводится информация по принципу «как будет», но он должен отталкиваться от действительности — зарегистрированных операций, существующих справочников. Планирование грешит неопределенностью. Всегда есть вероятность ошибиться, не заметить какие-то особенности. Поэтому надо фиксировать, как должно быть, но ориентироваться на то, что есть. Например, ИТ-компания планирует бизнес-деятельность в области телекоммуникаций. Естественно, она не может предсказать наверняка, с какими видами затрат столкнется, какие потери закладывать. Идеальное решение — приобрести уже существующий справочник какой-нибудь телекоммуникационной компании. Практически для каждой отрасли можно найти типовые справочники. Покупка будет не очень дорогой и крайне полезной. Не всегда стоит изобретать велосипед — порой достаточно сформулировать свои требования и попытаться найти нужный справочник. 9 9 Основные справочники Основные справочники группируются по тем же категориям, что и функции ERP-системы. 1. Финансовый справочник учетных регистров, включая управленческую аналитику Любому предприятию нужно разработать учетный классификатор — план счетов. Это некое дерево, которое подразумевает сами учетные регистры, аналитику и т. д. Иногда на практике к статьям затрат и статьям доходов относятся как к разным справочникам. В действительности они и есть разные. Но в системах они размещены в одной сущности под названием «План счетов». Группы активов — тоже, казалось бы, отдельная сущность. Однако и она находится в плане счетов. Правильнее формировать справочники из нескольких субсправочников («доходы-расходы», «виды услуг — виды продукции» и т. п.). Вопервых, это экономит место на диске. Во-вторых, помогает связать друг с другом статьи затрат и статьи доходов. Понятийно это один справочник, но пользоваться им будут разные люди, и система должна обеспечивать уровень безопасности, при котором пользователи видят только те элементы справочников, доступ к которым им разрешен. Сотруднику, работающему с доходами, совсем необязателен доступ к статьям затрат. Более того, на некоторых предприятиях (например, оборонного комплекса) это может быть сугубо конфиденциальная информация. Также исключение лишней информации устраняет вероятность ошибки ввода. 2. Логистика. Справочник товаров и услуг Это один справочник, который содержит то, что вы закупаете и производите. В производственных компаниях из-за специфики комплектации товара справочники изделий дополняются справочниками групп изделий, узлов, комплектов, рецептов и т. п. Если на предприятии из разных компонентов собирают компьютер, в таблице он связывается с этими компонентами. Производственные справочники представляют собой целый комплекс справочников, поскольку в них 1 10 существуют еще справочники маршрутов производства, производственных площадок и т. д. Разные справочники могут частично друг друга дублировать. Например, в финансовой части в качестве аналитики выступают товарные группы. У кладовщиков есть эти же группы, но им требуется более детальная группировка. Поэтому соотношение товарных групп в редакции финансиста и в редакции кладовщика может быть «один ко многим». Ситуация, когда у кладовщика товарной группы нет, а у финансиста она есть, исключена. Экспертная система позволяет параллельно вести несколько справочников. При заведении аналитики по товарным группам для финансиста и для кладовщика система должна напоминать, что вы ввели новую классификацию для финансиста и ей не соответствует ни один элемент в справочнике кладовщика. Некоторые фирмы в качестве справочников используют финансовую структуру. Дублирующим ее справочником является структура организационная. В стандартных системах это один справочник с альтернативными иерархиями (см. понятие «Альтернативная иерархия» в главе «Управленческое планирование»). 3. CRM. Справочник ваших контрагентов Существуют разные мнения по поводу того, следует ли держать всех контрагентов в одном справочнике. Это зависит от типа бизнеса. Например, в идеологии CRM (CRM — корпоративная информационная система, предназначенная для улучшения обслуживания клиентов путем сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур на основе сохраненной информации и последующей оценки их эффективности) есть классификация: b2b, b2c. Если вы работаете по второму принципу (приобретаете у юридических лиц, а продаете конкретным физическим лицам), собирать всех заказчиков и поставщиков в одном справочнике смысла нет. Это совершенно разные объекты учета, разные элементы аналитики, 1 11 даже разные карточки учета. Более того, принцип b2c, например, для сотовой компании подразумевает справочник заказчиков с разной степенью детализации для разных систем или подсистем. Для целей планирования и учета трафика не нужно знать каждое конкретное лицо, которое приобретает сим-карту. Достаточно группировки по количеству абонентов на регион. Кто эти абоненты, неважно. А сотрудникам, которые выставляют счета (зачастую в отдельной системе — биллинговой), надо учитывать каждого абонента, фиксировать всю историю взаимоотношений с ним. Да, мы говорим об одном справочнике, но с точки зрения детализации и целей использования они очень разные. Помимо справочников контрагентов, которые делятся, как минимум, на поставщиков и заказчиков, существуют вспомогательные справочники. В некоторых организациях они перерастают по объему основные. Компании, торгующие через Интернет, интересуют виды доставки. Поэтому каждый товар классифицируется по виду доставки, а виды доставки дробят по регионам, чтобы видеть, кто что предпочитает, как работает почтовая служба и прочее. 4. Производство В производстве базовым справочником является Bill of materials, связывающий материалы друг с другом в комплекты. Bill of materials во многих системах называется спецификация изделия, в других — комплект, в третьих — отдельно учитываются узлы. Формирование такого справочника — задача не из легких, потому что изделия бывают альтернативными. Например, при сборе стульев используется определенная категория дерева, но для каких-то соединительных деталей сорт дерева непринципиален. При отсутствии необходимой древесины система должна сама предложить альтернативный вариант. В нее вводится понятие «альтернативное изделие», которое позволяет более гибко подходить к производству в условиях разветвленной классификации. «Потерявшись» в аналитике, сотрудник может не найти необходимый материал. Система страхует от подобных случаев, предлагая близкий вариант в другой группе. 2 1 12 Такие ситуации могут сорвать планирование. При планировании производства (например, через несколько месяцев произвести определенное количество компьютеров) система должна через справочник спецификации изделий сформировать план наличия этих изделий на складе и план поставки комплектующих. Здесь тоже пригодится технология альтернативных изделий. Если этого понятия в системе нет, она выдаст результат: по истечении такого-то срока предприятие сможет собрать лишь 20 компьютеров, хотя планировалось 40. При анализе причин выясняется, что на складе отсутствует необходимая модель вентиляторов. А на самом деле вместо этих вентиляторов можно брать другие. Производственная специфика дает понимание, насколько важно заранее продумать структуру справочника. 5.Кадры При формировании базового справочника нужно учитывать, что грамотная кадровая система включает работу не только с существующим, но и с будущим (равно как и с бывшим!) персоналом. С точки зрения целесообразности, эти категории лучше развести по разным справочникам, потому что режим работы с сотрудником и не работающим в компании человеком — разный; частота обращений к таким записям тоже неодинаковая. Например, в компанию поступает резюме, его обрабатывают. По резюме человек может учитываться вплоть до увольнения. Если по текущим параметрам резюме не устраивает или по открытым вакансиям не подходит, оно просто «висит» в системе. Когда вакансия откроется, вы нажмете на кнопку, и получите весь список людей, желавших работать на аналогичной должности. При работе с сотрудниками применяется другой принцип. Начисление зарплаты и бонусов, профессиональный рост, загруженность, курсы повышения квалификации и многое другое входит в работу с сотрудниками компании. Поэтому целесообразнее разделять категории людей в этих видах справочников, но непременно сохранять связь, чтобы, зайдя в карточку сотрудника, можно было посмотреть его резюме и 3 1 13 отследить процесс собеседований. И наоборот: если человек у вас уже не работает, вы всегда можете получить данные о нем — как работал, какие бонусы получал. В идеале можно отслеживать деятельность вашего сотрудника после его ухода из компании. Бизнес делают люди, и если ваш бывший сотрудник работает в компании, с которой вы сотрудничаете, полезно об этом знать. Итог по работе со справочниками: разработка справочников — это отдельный проект. Ввод данных В идеале пользователь вообще не должен задумываться о пунктах меню. Современные системы все больше тяготеют к процессно-ориентированным интерфейсам, с помощью которых одно событие (скажем, ввод счета к оплате) инициирует другое (генерация списка счетов к оплате на утверждение финансовому директору). Каждый пользователь видит на своем компьютере не сложное многоуровневое меню, а список ближайших задач. Работа по принципу «списка задач» подразумевает сопряжение учетной системы с Outlook или с персональным менеджером задач и существование системы напоминаний (например, что пришел счет к оплате). Но счет к оплате может прийти лишь при наличии заказа на закупку. А он, в свою очередь, базируется на контрактах, которые завязаны на планирование бизнес-деятельности или проекта. В итоге получается взаимосвязанная цепочка. Допустим, человек заносит в систему список проектов. У каждого — свои этапы, под которые подстраивают закупки оборудования и (или) материалов. Менеджер проекта не может опуститься до напоминаний кому бы то ни было о покупке бетона. Этим должен заниматься ответственный: в день, когда пора заказывать бетон, приходит уведомление из системы — продлить договор с поставщиком. Напоминание появляется на мониторе компьютера, «кликаешь» на него и попадаешь в форму расширения договора. После заключения контракта его нужно завести в систему и в параметрах указать даты поставки — когда именно нужен бетон. Заказами на поставку может заниматься другой человек, у 4 1 14 которого на компьютере «выскакивает» свое напоминание — что система оформила заказ на поставку. Сотрудник подтверждает заказ и в электронном виде направляет его поставщику. При идеальном раскладе поставщик в своей системе обрабатывает заказ, создает запрос на отгрузку и на продажу. И так далее. Чтобы избежать путаницы в иерархии меню, надо выбирать систему, которая строится по принципу задач. Она должна быть проактивной и напоминать пользователю, что и когда делать. Еще один немаловажный момент — удобная форма ввода и дружественный интерфейс. Часто пользователей отпугивает громоздкость форм. Каждый хочет видеть лишь те поля, которые он использует. Поэтому на рынке востребованы не сами системы, а их деривативы — отраслевые решения. На мой взгляд, оптимальное решение — использовать все многообразие функций крупной системы, но настроенной под конкретную отрасль. Например, решение для торговли. Основные категории товаров разработаны и введены в систему. На всех формах ввода фигурируют поля, которые следует заполнять именно работнику торговли. Даже названия полей могут быть адаптированы под конкретную отрасль. Многие компании, специализирующиеся на доработке известных систем до уровня «отраслевое решение», идут еще дальше — выпускают решения для конкретного типа предприятий (супермаркетов, бутиков, магазинов класса DIY и т. п.). Компания Intentia — разработчик ERP-систем для конкретных отраслей. Если, например, Oracle выпускает бизнесприложение, а партнеры создают на его базе отраслевые решения, то Intentia изначально выпускает разные системы для конкретных отраслей. Есть Intentia for electricity, Intentia for process industry. Причем итоговый продукт — это не голая система, куда необходимо вводить все справочники, а система с преднастроенными справочниками. Из них достаточно убрать лишнее. И все! Судя по финансовым показателям и динамике роста Intentia, можно говорить о востребованности таких решений на рынке и серьезной отраслевой сегментации систем. Еще одно преимущество отраслевых решений — экономия 5 1 15 времени и денег на внедрение, потому что многое не придется создавать с нуля. Естественно, подобрать систему, настроенную именно под ваше предприятие, сложно. В ситуации, когда, например, торговая фирма планирует сервисную деятельность, которая со временем может стать основной, бессмысленно искать решение, удовлетворяющее обе потребности — текущую и перспективную. Лучше взять систему, где есть все, что необходимо на данный момент, а «будущие функции» все равно потребуют отдельной настройки. Извечный вопрос: кто под кого должен подстраиваться — клиент под систему или система под клиента? Отвечать на него следует в индивидуальном порядке. Значительную экономию денег и времени при внедрении системы обеспечивает подход «подстраивания» под систему: она диктует, каким должен быть бизнес. Но здесь есть подводные камни. Любой бизнес уникален. Так, бизнес компании British Petroleum в каждой отдельной стране не похож на другой. Если количество уникальных моментов превалирует или есть один, но самый критичный, правильнее перенастроить систему. Например, вы производите эксклюзивный продукт с помощью соответствующего, эксклюзивного персонала. Вы зависите от каждого такого сотрудника. Если ему не хочется меняться, и вы не можете на него повлиять или кем-то заменить, придется под него подстраивать систему. Надо понимать: сможете ли вы так замотивировать персонал, чтобы он изменил стиль своей работы. Дело даже не в саботаже, хотя часто приходится сталкиваться именно с этим. Такова природа человека — мы не любим новое. Поэтому при внедрении системы важно учитывать человеческий фактор — насколько люди готовы к переменам. В быстроразвивающихся отраслях, вроде ритейла, телекоммуникаций, услуг, работают динамичные и гибкие люди. Они обычно легко переходят на типовое решение. В промышленности (металлургия, машиностроение и т. п.) все строится на традициях. Из производителей автомобилей лишь Toyota меняет эти пред6 1 16 ставления, а остальным присуща преемственность поколений. Чем больше династий, тем сплоченней коллектив, и это приводит к скептическому отношению к переменам. Обнаружив в форме непонятные поля, сотрудники настораживаются. Особенно те, кто занимались исключительно бумажным учетом и никогда не задумывались о страховом запасе, минимально пополняемом запасе, точке дозаказа и т.п. Однако эти поля были созданы для «всех возможных» отраслей или являются настроечными. Избежать их невозможно — таковы требования автоматизации процессов. Это лишь маленькийпример, в каждой форме таких нюансов может быть масса. Нормальная система позволяет ликвидировать сложности: если поле не используется, пользователь, наделенный соответствующими правами, делает его невидимым. После «косметического» изменения оставшиеся в форме поля эргономически распределяются по странице, ликвидируя «дырки». Таким образом, структура меню (последовательность подсистем и модулей) настраивается под конкретного пользователя. Пользовательские настройки лучше производить, создавая роли, о которых мы говорили в главе 2.3 «Постановка оперативного учета». Одна или несколько В среде ИТ-специалистов это вопрос из разряда «философских»: вам нужна одна общая система или несколько разных? В мире преобладают две тенденции: комплексность (укрупнение) и сервисность. Первая подразумевает наличие одной большой системы, которая охватывает весь бизнес. Плюсы такого подхода — единообразие интерфейсов и централизация всех данных, что позволяет использовать на предприятии единую версию информации. Есть у комплексной системы и свои недостатки. В частности, ее сложно дезинтегрировать. Ну, нет у вас сейчас потребности (желания, денег, времени) внедрять модуль 7 1 17 «отгрузки», вполне хватает «производства» и «логистики». А система без этого модуля работать не может. В «урезанном» варианте при списании готовой продукции со склада невозможно пользоваться стандартными функциями отгрузки — комплексная система потребует указать номер заказа, код заказчика и т. п. Приходится брать на вооружение функцию фиктивного списания товарных единиц со склада, которая обычно используется для корректировки остатков (в том числе при инвентаризации). После того как вы обучите пользователей такому списанию, вам придется их переучивать, когда решите внедрить модуль «отгрузки». Это еще один маленький пример. Интегрированные крупные системы недаром так называют: они настолько крупные, что попытка дезинтеграции оборачивается серьезными дополнительными тратами. Принцип комплексной системы — сделать все сразу в одном учетном кольце. Нужно заранее обдумать, как внедряемый модуль будет отражаться в финансах, потому что впоследствии перенастроить финансовую часть логистики и производства не удастся. По этой же причине сначала формируются классификаторы, а потом следует внедрение. Вторая идеология — сервисная — предусматривает, что конкретную задачу выполняет отдельная программа. И пусть у каждой из них есть свои справочники — они должны хорошо взаимодействовать, чтобы однотипные данные систем не противоречили друг другу. Плюс сервисного подхода — результативность. Например, вы автоматизируете работу с заказчиками (точечная автоматизация) и внедряете соответствующий модуль, не дожидаясь синхронизации с кладовщиками. У них — другая система. Минус этого подхода в том, что трудно отследить единую версию данных. Системы должны хорошо интегрироваться одна в другую. Если возникнет недоверие к отчетности одной из систем, придется проверять все остальные — две, три, а то и все 10, где могла зародиться ошибка. В разработке сервисных систем есть такое понятие — единое хранилище данных, — куда каждая система отсылает сформированные показатели. Здесь же находится единое 8 1 18 хранилище справочников. И не может быть несколько равнозначных справочников по одному и тому же предмету. Важное свойство сервисного подхода — выполнение локальных задач без учета потребностей других участников. Например, для управления бизнесом в целом нужно пять аналитических признаков изделия, а система формирует только три. Она — дешевая и быстро внедряется. Отдел продаж доволен, а топменеджмент — нет, потому что два важных аналитических признака в общей отчетности по предприятию отсутствуют. Приходится брать их не в момент совершения учетного события, а «обходными экспертными путями». Доверие к таким сведениям невелико. И подобных «неудобностей» при сервисном подходе — сотни. Отчет Мы выделяем три вида отчетности: динамическая, статическая и интерактивная. Выбор в пользу статических отчетов предопределяет привычка и специфика бизнеса. Статическая отчетность предназначена для распечатки и генерируется в заведомо неизменяемом формате. Например, PDF или специальном формате системы. Хотя многие системы позволяют делать баланс предприятия в виде таблицы Excel, эта универсальность может навредить: в таком формате легко внести изменения. Конечно, аналитик, формируя отчет, не будет трогать баланс. Но если отчет создает сама система (например, ежедневно генерируется отчет о производственных остатках), его нужно защитить, чтобы сохранить достоверность представленных руководству цифр. В динамической отчетности можно буквально путешествовать и «сверлить» данные. Например, вы хотите получить детальные сведения, из каких показателей формировалась отчетность. Вы попадаете в суботчет, где каждая цифра расписана по субсчетам, выбираете другой показатель и смотрите, в результате каких операций он формировался. Интерактивный отчет — то, к чему тяготеют все системы. Он дает возможность получить любой отчет в рамках определенной компетенции пользователя. 9 1 19 Допустим, вам необходимо узнать объем продаж по регионам в разрезе продавцов и категорий товаров. При интерактивной отчетности вы заходите в форму, где указываете, что строки — регионы, в столбцах — продавцы, а еще продавцы должны разделяться по категориям товаров. Затем нажимаем на кнопку и получаем отчет. Если бы он уже существовал в системе, то назывался бы «отчет по продажам по регионам». При этом в нем отсутствовали бы данные в разрезе продавцов. Или вы захотите получить отчет по регионам и категориям, а внутри — сведения по продавцам, чтобы определить, кто из них лучше продает категорию «алкоголь». За несколько секунд вы формируете несколько отчетов в удобном для вас формате и в разрезе необходимых данных. Для сравнения: при статическом подходе придется обращаться к разработчику, чтобы он в течение недели или двух создал такую опцию. О. Урнев (генеральный директор «Ижорского трубного завода»): «Если бухгалтерская отчетность подчиняется определенным законам, которые мы обязаны не нарушать, то управленческая отчетность — это воля руководителя, что мы будем отслеживать, что отражать в отчетах и для чего. Главное требование управленческой отчетности, в отличие от бухгалтерской, — не форма и не способ визирования или предоставления, а удобство восприятия. Управленческая отчетность, которую сложно усвоить за нескольких минут, становится бесполезной. Она должна обладать двумя признаками — оперативностью и удобством для восприятия. Мне приносят отчетность по проблемам, спецификациям, узким местам на производстве. Все очень разное: у одних — издержки, у других — выполнение заказов, третьи маются с загрузкой агрегатов, которые обеспечивают максимальную производительность линии. На каждом предприятии есть свои болевые точки. Я знаю компании, где управленческая отчетность сводится к предоставлению данных о том, сколько денег пришло и ушло. Остальное неважно, поскольку бизнес — 2 20 несложный и строится на денежных потоках. А у нас все упирается в производство. И нам очень важна отчетность по переделам агрегатов. Она предоставляется в плановопроизводственный отдел, директору по производству, техническому и генеральному директорам. Отчеты максимально упрощены и отражают минимум показателей, который необходимо контролировать посменно и ежедневно. Всего по производству отслеживается 12 показателей. Я беру только производительность по агрегатам, причем не на всех участках, а лишь на самых болезненных — учет складских показателей и показателей по персоналу. Ежедневно я смотрю отчеты производства продукции за смену и за сутки, отслеживая работу агрегатов, которые для данного сортамента работают на полную мощность, без запаса. Это узкие места, определяющие производительность всей линии. Спустя месяцы мы можем решить вопросы по этим агрегатам и не будем отслеживать их работу. Почему мы не уделяем внимание другим точкам? Не потому, что они менее важны. Просто всего не охватишь, а управленческая энергия конечна, надо расставлять приоритеты. Остальные места контролируются, но с меньшей периодичностью. Если я не буду отслеживать работу этих агрегатов, вероятно, важность данного отчета для остальных директоров будет потеряна. К тому же я сам должен быть в курсе происходящего. Чтобы, увидев отчет о выполненной за сутки работе, не задумываться — много это или мало. Мне, как руководителю, необходима качественная оценка, а не констатация факта. В производстве дать качественную оценку проще, чем в финансовой деятельности, стратегическом планировании, при работе с персоналом. Ведь управление персоналом — достаточно инертный механизм: сегодня ты снизил затраты на обеспечение, а завтра потеряешь работников. Под управленческую отчетность выстраивается и оперативное совещание. Поводом для его проведения я считаю внезапно возникшую проблему, которую нельзя уладить 1 2 21 мгновенно, так как нет стандартного пути решения; приходится собирать людей и проводить интеллектуальный штурм. Выход управленческой отчетности — тоже повод для оперативного совещания. А если процесс отслеживается посменно, значит, собираться на обсуждения надо с такой же периодичностью. Финансовую отчетность я ежедневно не отсматриваю, этим занимается финансовый директор. Даже он не делает это каждый день. Финансовая отчетность не может быть ежедневной, в полном формате она реальна лишь ежемесячная. Вероятно, есть организации, которые делают ежедневный баланс. Так или иначе, финансы напрямую связаны с производством. Наиболее актуальные финансовые позиции должны поддерживать производство и в меньшей степени — то, что сегодня не является критической точкой». Ликбез по многомерным базам данных Внедрение можно разделить на два этапа: создание справочников и осуществление точечных настроек, под которые впоследствии разрабатываются отчеты. Каждый привык видеть информацию в определенном виде, а не так, как она предстает в системе. Человек так устроен, что, получив данные, он непременно захочет получить их в еще каком-нибудь разрезе или дополнить другими показателями. Системы, которые не обладают функцией динамического построения отчетности, на этом и рушатся. Казалось бы, идиллическая картина: пользователи вводят данные, справочники корректно сформированы, система отлично внедрена, но руководство не видит нужных сведений. Эффективность внедрения системы для управленца заключается в том, насколько быстро она может предоставить данные, которые хочет управленец. В качестве ликбеза расскажем о реляционных и многомерных базах данных. Реляционные — это привычные столбцы и строки. Такая база позволяет аккуратно и компактно хранить документы. Сначала зародился именно такой тип баз 2 22 данных. Но впоследствии встал вопрос: как интерпретировать полученные сведения? Для получения отчета приходится сводить множество таблиц: отчет в разрезе по продавцам — в одной, по регионам — в другой, отгрузки — в третей, категории — в четвертой. А в следующий момент времени понадобится новый набор таблиц. Процесс увязывания реляционных таблиц растянут во времени. К тому же на предприятии формированием отчетов занимаются сотни людей, и на систему ложится огромная нагрузка. А при современной динамике бизнеса цифры изменяются постоянно. Пока вы формируете отчетность из различных показателей, они успевают измениться. Поэтому переход к многомерному подходу стал логичным. Многомерное хранение данных подразумевает множество измерений. Цель многомерности — в любой момент любые данные можно сопоставить друг с другом. Правда, это приводит к избыточности: некоторые данные не сочетаются; никому никогда не придет в голову их связать. В таких хранилищах нет операций — лишь итоговые результаты, только метаданные (метаданные в общем случае — это данные, характеризующие или поясняющие другие данные. Например, значение «123456» само по себе недостаточно выразительно. А если значению «123456» сопоставлено достаточно выразительное имя «почтовый индекс» (что уже является метаданными), в этом контексте значение «123456» более осмысленно — можно извлечь информацию о местоположении адресата, имеющего данный почтовый индекс.). Отсюда возникло чисто физическое противоречие: чтобы иметь такие отчеты, необходимо перекачивать данные из реляционных таблиц в многомерные. При любом режиме эксплуатации, комплексном или сервисном подходе, у вас будет две версии правды — в реляционном и многомерном виде. В каждой компании обычно есть и реляционные, и многомерные, поскольку у каждой из них свое предназначение: первая обеспечивает хранение документов, вторая — их анализ. В рамках первой также может формироваться отчетность — статическая или динамическая. Интерактивная в 90% случаев 3 2 23 имеет дело только с многомерной базой. При построении систем необходимо наладить между ними четкое взаимодействие. Новый поставщик в реляционной системе должен автоматически появиться в многомерной, а не наоборот. В качестве первоисточника обычно выступает реляционная база, потому что в многомерной нет текстов, за исключением наименований аналитических элементов, счетов или их кодов, названий или кодов товарных групп. Там содержатся все классификаторы и цифры — метаданные, которые являются суммарными данными. До недавнего времени многомерные системы характеризовались тем, что через них можно было только смотреть данные. Но любой аналитик хочет вводить информацию, например, чтобы проводить сценарный анализ «что будет, если...»: что произойдет, если будут такие затраты и такой уровень налогов? Многие системы названного класса предусматривают подобные опции прогнозирования. Однако человечество шагнуло еще дальше и пришло к осознанию, что бюджетирование лучше делать в многомерных системах. Бюджетируя, мы анализируем и, анализируя, бюджетируем. Создавая бюджет с нуля, приходится обыгрывать различные версии: бюджет не статичен при создании и во время получения фактических данных. Сравнивая план с фактом за первый квартал, вы корректируете план на следующий квартал в зависимости от результатов. Появляется основная версия, версия скользящего бюджета и т.д. Процессы анализа и планирования, как оказалось, неразрывны, поэтому логичнее проводить операции в одной системе — многомерной. Как следствие — жесткие требования, которые ранее предъявлялись к ERP-системам, оправдались в отношении систем многомерных. Анализ деятельности предприятия в целом осуществляют сотни пользователей, и нужно задумываться о разграничении доступа, дружественном интерфейсе и прочем. Все требования, которые мы перечислили выше, предъявляются к многомерной базе. Подводным камнем является ее избыточность. Огромное количество данных и 4 2 24 множество пользователей увеличивают нагрузку на аппаратное обеспечение в десятки раз больше, чем при работе с реляционной ERP. Поэтому реализация бюджетного управления в многомерной системе — далеко не тривиальная задача, и она гораздо сложнее, чем простые формы ввода в ERP-системе. Мы выделили данные, которые должны быть в ERPсистеме, но, как говорилось ранее, это всего 30% данных, которые создаются на современном предприятии. Есть еще приказы, распоряжения, протоколы, тексты договоров. Где хранить их — вопрос уже не к управленческому учету, а к системе документооборота. Глава 1.2. Классификация систем обеспечения управленческого учета Разобраться с существующими на приложениями поможет следующая таблица. рынке бизнес- Таблица 1.1. Категории бизнес-приложений Основные решаемые задачи Существует BPM ли по данной (EPM, функции CPM) некий вид отдельных систем Управ- EPR MRP SCM WMS CRM ЕСМ I, II ление финансами BI 1 Управленческое планирование Стратегическое + управление Управление по + системе KPI (score carding) Сценарное планирование Бюджетное управление Финансовая консолидация Управленческий контроль X X X X + X + X + X X 5 2 25 Управленческий + анализ Трансформация фи- + нансовой отчетности Учет Ведение бухгалтерского учета Ведение финансового учета Конверсия финансовой отчетности Управление 3 ресурсами предприятия Финансовый контроллинг Калькуляция себестоимости ГП Управление закупками Управление НСИ Управление складами Управление реализацией продукции Взаимоотношения с заказчиками Маркетинг Электронная коммерция Производственное планирование X X X 2 Цеховое управление Управление проектами Кадры Управление 4 цепочками поставок Транспортное управление Цепочки поставок + X X + X X X X X + X X + + X X X X X X X + X X + + X X X X + X X + + X X X + X + X X + X X 6 2 26 Взаимодействие с поставщиками Взаимодействие с дистрибьюторами Электронный обмен + документами 5 Управление неструктурированн ой информацией Организационно- + распорядительный документооборот X X X Договорной + документооборот Управление + корпоративным порталом X Управление + знаниями Управление + конструкторскими работами X X X В строках этой таблицы перечислены основные задачи информационного обеспечения практически любого предприятия. Функциональное наполнение каждой остается «за кадром»; подразумеваются стандартные функции той или иной области менеджмента. Например, задача «Маркетинг» в фирме, занимающейся продажей рекламы, довольно сильно отличается от маркетинга компании — дистрибьютора импортного врачебного оборудования. И, тем не менее, обе найдут в стандартном маркетинговом наборе ERP-системы следующие функции: • Маркетинговые кампании и акции. Рассылки. • Обработка лидов и т. п. Как видно из таблицы, практически для каждой задачи существует несколько отдельных (stand alone) систем. Это доказывает теоретическую возможность автоматизации любой функции вашего предприятия отдельными мини-системами (сервисами). 7 2 27 Начиная с пятой колонки, в таблице перечисляются общеизвестные категории бизнес-систем. В данной классификации имеются в виду лишь готовые системы. Каковы плюсы и минусы разработки индивидуальных систем «для себя», вы можете прочесть в следующих разделах. BI – business Intelligence - широкий класс приложений и технологий, предназначенных для решения задач сбора, хранения и анализа информации. Конечной целью любого ВI-приложения является улучшение качества принимаемых в компании решений путем предоставления бизнес-пользователям всей необходимой информации. Без инструментов business intelligence не обойтись в сферах, где вращаются большие объемы данных: - потребительские товары; - розничная торговля; - финансовые услуги; - транспортные услуги. Последний обзор Accenture выявил, что из 162 опрашиваемых CIO 40% уже используют BI для поиска конкурентоспособной ниши; 76% будут инвестировать в BI и в хранилища данных в ближайшие месяцы; 57% рассматривают BI как основной компонент для конкурирующих преимуществ в ближайшем будущем. СРМ – по определению Gartner Group подразумевает использование методов и средств BI совместно с методологиями, процессами и метриками для управления эффективностью бизнеса (performance). При этом принципиальное значение имеют два обстоятельства: ориентация СРМ-систем на применение различными сотрудниками компании и мощная интеграционная составляющая, заложенная в архитектуру и функциональность СРМ-приложений. В практическом плане концепцию СРМ можно определить как интеграция и автоматизация процессов мониторинга систем сбалансированных показателей, аналитических приложений и средств бизнес-планирования. ERP-система - Enterprise Resource Planning System система планирования ресурсов предприятия, корпоративная 8 2 28 информационная система (КИС), предназначенная для автоматизации учета и управления. Как правило, ERP-системы строятся по модульному принципу и охватывают ключевые процессы деятельности компании, интегрируя все ее подразделения в единую систему. Главный «ингредиент» любой ERP-системы - унифицированная база данных, хранилище всех сведений и показателей из различных системных модулей. Термин ERP, по сути, не соответствует своему определению. Забудьте о планировании (Planning), ERP-системы для этого не предназначены. И о ресурсах (Resource) тоже забудьте – термин не дает ясного представления о том, что именно учитывает система. Но запомните часть, касающуюся предприятия (Enterprise), - в нем сущность ERP-системы. Исторически ее концепция стала развитием стандартов MRP (material requirement planning - планирование материальных потребностей) и MRPII (manufacturing resource planning планирование производственных ресурсов). Важно отметить, что это были именно общепринятые стандарты. Второй термин отличался от первого включением производства: в этот стандарт вписывались расчеты производственных ресурсов и их загрузка для корректного распределения материалов. Потом на свет появился термин ERP. Базировавшийся на стандартах MRP и MRPII, но сам не являвшийся стандартом, он породил неразбериху в толковании. Разные компаниипоставщики называют предлагаемые продукты ERP-системами. Начинается разночтение. Что должно входить в ERP? Попадает ли сюда управление персоналом? Вроде, это часть управления предприятием, но точного стандарта нет. Поэтому неясно, можно ли систему без модуля по управлению персоналом считать ERP. По мнению многих, в понятие ERP входит функционал MRP и MRPII плюс обработка финансов, кредиторка/дебиторка, денежные потоки. SCM – supply chain management, управление цепочками поставок - это процесс планирования, внедрения и контроля операций цепочки поставок. Управление охватывает все 9 2 29 движение и хранение товаров и незавершенной продукции от момента ее возникновения до момента потребления. Управление цепочками поставок включает: - снабжение; - закупку; - перемещение; - логистику; - взаимодействие с партнерами, поставщиками, посредниками, сторонними организациями, оказывающими услуги, и покупателями. WMS – warehouse management system - система управления, обеспечивающая комплексную автоматизацию управления складскими процессами. Она является ключевой составляющей цепочки поставок и контролирует движение, хранение товаров на складах, а также отвечает за получение, транспортировку, раскладку и сортировку товаров. Как вы, наверное, успели заметить, многие категории систем функционально пересекаются. Мы рекомендуем вам быть осторожными и взвешивать все «за» и «против», выбирая систему для решения сложных задач. Тут перечислены не все категории систем. Мы не указывали те из них, которые решают узкие вопросы. И, тем не менее, системы, которые подразумеваются в третьей колонке, могут быть совершенными и выполнять свои функции гораздо лучше, чем, например, система класса ERP. Важное замечание в адрес ERP: здесь имеется в виду «классический» набор функций систем, которые принято называть ERP. В настоящее время многие производители ПО включили в состав предлагаемых модулей функции управления эффективностью бизнеса. Но в силу того, что управленческое планирование наиболее эффективно работает на многомерной БД, предлагаемые с такой функциональностью модули, по сути, являются разными системами от одного и того же поставщика, хотя и прекрасно интегрированными между собой. Примеры: 3 30 • Компания SAP (Германия) производит продукт ERP-класса SAP R/3 и систему управленческого планирования и анализа SAP SEM. • Компания Oracle (США) производит продукт ERP-класса Oracle e-Business Suite и систему управленческого планирования и анализа Oracle ЕРВ (Hyperion). Поскольку ИТ-мир изменяется весьма стремительно, выбирая систему, стоит прислушаться к мнению независимых аналитиков, таких как Gartner, AMR Research, IDC, чтобы получить новейшую классификацию систем. Хотя, конечно, основополагающие принципы еще долго будут оставаться неизменным. С ними вы можете познакомиться в следующей главе. Глава 1.3. Подходы к выбору программного приложения Следуя рекомендациям этой книги, вы уже смогли разработать необходимый пакет документации, на которой базируется управленческий учет. Но постановщик задачи — это специалист, который находится на стыке двух областей, — предметной и компьютерной. Разрабатывать или внедрять готовое Кто такие разработчики типовых систем (отраслевые решения, реализованные на базе типовой системы, тоже можно назвать типовыми)? Это компании, которые собирают лучшие практики бизнеса в вашей профессиональной области. Они не ставят на вас эксперименты и не ловят каждое ваше слово («чего изволите?»). Порой, они знают о вашей отрасли гораздо больше вас и могут сегодня предвидеть задачи, с которыми вы столкнетесь завтра. В случае же с индивидуальной разработкой вы получите функциональность системы, которая нужна здесь и сейчас, с перспективой регулярно обращаться за расширением возможностей. Грубо говоря, при заказной работе вы будете получать то, что было остро необходимо вчера. А при покупке готовой системы надо, чтобы разработчик или поставщик опережал видение вашего бизнеса «на два шага». 1 3 31 СОЗДАТЬ ИЛИ КУПИТЬ? У организаций есть две возможности для работы с программным обеспечением СРМ: создать собственное или купить готовый пакет. Чтобы сделать правильный выбор, надо знать все плюсы и минусы каждого варианта. СОЗДАНИЕ ПРОГРАММНОГО РЕШЕНИЯ СРМ Внедрение решения влечет за собой выбор технологической платформы и создание всех компонентов, необходимых для СРМ. Кто-то должен создать модель предприятия; написать программы и процедуры для расчета делового регламента; разработать пользовательский интерфейс, с помощью которого будут контролироваться различные СРМ-процессы; описать порядок формирования отчетных и аналитических форм. Чтобы внедрить такое решение, организации могут совместить стандартные промышленные технологии (например, электронные таблицы для отчетности) с базой данных OLAP (оперативная аналитическая обработка данных), которая используется для построения модели. ЗА: Выгоды от создания собственного СРМ-решения: - Организация получает именно то, что запрашивает. Нет необходимости выбирать между функциональностью и внешним видом, поскольку система может быть полностью приспособлена к нуждам компании. - Разработка решения контролируется самой организацией. Она определяет порядок и уровень функциональности на выходе. ПРОТИВ: Причины, по которым фирма должна серьезно подумать, нужно ли ей создавать собственную СРМ-систему: - Результирующее решение будет ограничено опытом и технологической компетенцией, которых достиг персонал компании. Технологии шагают вперед с пугающей скоростью, многие отделы информационных технологий (IT) просто не успевают за их развитием. Подобным образом организации опираются только на собственные методы управления, а они могут не отражать последних достижений в области эффективного менеджмента. 2 3 32 - Поскольку все компоненты и соответствующую функциональность нужно будет разрабатывать и внедрять целиком, внедрение «доморощенной» системы почти наверняка займет гораздо больше времени, нежели покупной. - Решения, разрабатываемые самой организацией, обходятся дорого. Хотя изначальная цена технологии может показаться невысокой, чтобы точно оценить предстоящие расходы, в том числе надо учесть стоимость людских ресурсов, необходимых для создания, тестирования и внедрения решения. - Поддержка СРМ-решений, сделанных на заказ, может оказаться дорогой, если изменится технологическая платформа. Например, если XML (расширяемый язык разметки) станет принятым стандартом для интеграции систем, СРМ-систему нужно будет модифицировать для поддержки будущего внедрения Информационной системы управления ресурсами (ERP), использующей этот стандарт. Такие изменения могут привести к глобальной переработке программы. - Организация будет вынуждена самостоятельно производить бета-тестирование - это придется часто делать в производственной среде. ПОКУПКА ПРОГРАММНОГО РЕШЕНИЯ Покупка решения заключается в выборе программного пакета, разработанного для СРМ, который затем будет сконфигурирован под нужды организации. Типовые СРМ-пакеты разрабатываются на основе гибкой модели предприятия и поставляются с администраторским интерфейсом, который упрощает настройку деловых регламентов, пользовательского интерфейса, отчетов и методов расчета. Поскольку пакеты разрабатываются специально для СРМ, большое количество функций входит в «коробочный» вариант. В общем случае внедрение системы сводится к простому выбору опций. ЗА: При условии, что правильно выбран поставщик (есть рекомендации компаний, которым он успешно предоставлял СРМ-решения), выгоды от использования данного подхода будут следующие: 3 33 - Организация извлечет выгоду из опыта других компаний - на данный момент и в будущем. Крупные поставщики программного обеспечения работают с сотнями компаний. Они используют их опыт при текущей разработке и для усовершенствования предоставляемых решений. - Решение может быть внедрено быстрее, поскольку пользовательский интерфейс и бблыиая часть функциональности уже разработаны. Запуск нужных функций в данном случае заключается в их выборе из списка опций. - Программное обеспечение предоставляет готовые решения проблем, о которых на момент создания новой системы организация может и не знать. Например, решение может предоставляться со встроенным инструментарием поддержки различных методов расчета, который позволит конечным пользователям анализировать данные по управлению взаимоотношениями с заказчиками (концепция CRM), даже если такая функциональность изначально не была запрошена. - Бета-тестирование системы произведено другими компаниями. Она работает и может быть предоставлена оперативно. Благодаря опыту предшественников успех внедрения и использования можно оценить до начала дорогостоящего процесса внедрения. - В общем случае СРМ-пакеты разрабатываются так, чтобы в них было легко вносить изменения. Персоналу, который занимается финансами, позволено вносить собственные корректировки, а затем быстро и легко включать в корпоративную систему. Лучшие пакеты также осуществляют проверку целостности. Она позволяет убедиться, что внесенное изменение не влечет за собой двояко трактуемые результаты и иные проблемы. Например, разумное решение не позволит одному и тому же элементу, такому как «Операции в Европе», дважды появиться в структуре организации. Это помогает избежать дублирования всех результатов и данных, относящихся к данному элементу. - Спустя некоторое время поддерживать покупные решения оказывается гораздо дешевле. Поставщики 4 3 34 программного обеспечения могут распределить стоимость обслуживания приложения между сотнями покупателей. Поэтому за относительно небольшую плату покупатель получает отдельную команду профессионалов, постоянно работающих над улучшением своего программного продукта. - В определенной степени такие системы «защищены от времени». Поставщики программного обеспечения заинтересованы в том, чтобы их решения работали с самыми новыми технологическими платформами и покупатели продолжали платить ежегодные взносы за техническое обслуживание. Если произойдет значительный сдвиг технологий, преуспевающие поставщики разработают новые продукты и предоставят своим покупателям возможности для миграции. ПРОТИВ: Несмотря на то, что есть причины предпочесть покупке СРМ-системы ее создание, тщательный выбор поставщика и системы может свести на нет эти проблемы: - Возможно, организации придется выбирать между возможностями и пользовательским интерфейсом. В общем случае пользователи работают так, как было запрограммировано в системе. Иначе они не смогут воспользоваться преимуществами системы. - Технология, на основе которой поставщик разрабатывал систему (например, база данных), может отличаться от технологии, используемой компанией. Значит, понадобится больше времени для интеграции с существующими системами, а также обучение персонала работе с другой технологией. - Первоначальные затраты слишком очевидны и могут затруднить получение одобрения руководства на старт проекта. - Если поставщик неправильно понимает потребности организации, система может работать не так, как предполагалось, или (в некоторых случаях) не работать вовсе. - Продукт может оказаться ненадежным, службы технической поддержки - неквалифицированными. Это сделает решение нежизнеспособным. 5 3 35 - Поставщик может прекратить использование продукта или даже выйти из бизнеса. Тогда программа лишится технической поддержки и придется снова тратить деньги - на внедрение нового продукта. Из-за сложности и широты СРМ-решений большинство СРМ-пакетов предлагают открытый подход. То есть программное обеспечение имеет встроенную функциональность, которая расположена на поверхности основной базы данных. Это дает организациям дополнительные возможности. Необходимо, чтобы выбранный поставщик подтвердил оказание технической поддержки в случае корректировки системы. Если такого подтверждения нет, выбранное решение превратится в самое худшее из всех возможных: все «против» без гарантий хотя бы одного пункта «за». Другая опасность - выбор пакета, который в соответствии с маркетинговыми материалами поддерживает СРМ, но изначально не был предназначен для этой цели. Такой подход также объединит в себе «против» как возможности создания системы, так и возможности ее покупки, и отдельные «за» - и все это за высокую цену. Большая или маленькая Итак, если вы отдали предпочтение варианту с готовой системой, нужно определиться, по какому пути идти дальше — большой комплексной системы или сервисов. Мы, в свою очередь, расскажем, какие существуют тренды в информационных технологиях мира и как (возможно!) он будет развиваться завтра. Разумный выбор масштабов зависит от размера вашей компании. Это нетривиальный вопрос, потому что если на него легко ответить сегодня, то завтрашний день скрыт под покровом тайны. Если в настоящее время ваше предприятие преуспевает и есть планы будущих приобретений в отрасли или диверсификации бизнеса, бизнес может превратиться в холдинг. Но не так все просто, особенно если говорить о диверсификации. Превращая свою компанию в холдинг, контролирующий несколько разных бизнесов, вероятно, будет 6 3 36 легче представить каждый из них как самостоятельное предприятие. С точки зрения автоматизации, в данном случае речь идет не об одной комплексной системе, покрывающей все фирмы, а о нескольких системах, созданных под каждую из них. Это особенно актуально для многопрофильных холдингов. Посудите сами: типовой многопрофильный холдинг в России на сегодняшний день включает в себя, как минимум, следующие виды субпредприятий: • производственные предприятия (одно или несколько); сервисные предприятия; • обслуживающие производственные предприятия в области ремонта; • поддержания чистоты территории; • коммуникаций и т. д. Например, торговый дом и снабженческая организация, которая порой является частью управляющей компании. Характер деятельности этих бизнесов отличается от всех предыдущих. В итоге мы имеем дело с обособленными предприятиями. Часть из них укрупнять и развивать не планируется, другие будут меняться, даже если мы этого не хотим. Все завязано на стратегии. Ее нужно рассматривать с той точки зрения будущего компании — насколько самостоятельной должна стать каждая из контролируемых вами линий бизнеса. «Тяжелая» или «легкая» Размер вашей компании сильно влияет на круг систем, из которых вы будете выбирать. Системы делятся на «легкие» и «тяжелые» (см. табл. 3.2). «Тяжелые» — это не негативный, а классификационный признак комплексной, многофункциональной и постоянно «растущей» системы. В их «арсенале» появляются новые функции, специфичные для конкретных отраслей; особенно если речь идет о стремительно развивающихся во всем мире отраслях (ритейл, телеком, сервисные отрасли). «Легкие» системы обладают основным функционалом, ориентированным в основном на финансовый и бухгалтерский учет. В них типы производственных учетов и 7 3 37 управления ограничены. Если компания представляет собой несколько разнопрофильных суббизнесов, в каждом из которых есть персонал, работающий с будущей системой управленческого учета (в пределах нескольких десятков пользователей), возможно, стоит выбрать для них «легкую» систему. Самым главным признаком «легкости» является то, что «легкие» системы не станут «тяжелыми». То есть если вы покупаете «легкую» систему на предприятие, растущее от 50% в год — по обороту, документообороту, количеству персонала и учетных событий, — она со временем может не выдержать объема регистрируемых данных. Если в перечне ваших дочерних компаний есть такие, где число людей, работающих с будущей системой управленческого учета, не превышает нескольких десятков, покупайте для каждой из них «легкую» систему. При этом для анализа всех данных, регистрируемых в таких системах, организуйте в холдинговой компании централизованное хранилище данных. Минус этого варианта проявится, если какое-то из дочерних предприятий сильно вырастет. Тогда вы столкнетесь с проблемой, о которой я уже говорил, — с невозможностью обработки большого количества данных. Таблица 1.2. Рекомендации по выбору «размера» системы Количество субъектов учета в виде ролей до 50 от 50 до 200 более 200 до 500 более 500 Рекомендации «Легкая» система Пограничное состояние «легкой» системы – необходимо анализировать количество обрабатываемых документов Система среднего класса, но необходимо проверить «сайзинг» «Тяжелая» система 8 3 38 Момент выбора категории системы — чуть ли не самый важный. От него зависит инвестиционная составляющая. Выбрав «тяжелую» систему, вы обрекаете себя на большие затраты по ее покупке, дорогостоящее (миллионы долларов) и длительное (от одного до трех лет) внедрение. В случае с «легкими» системами в пересчете на одно небольшое предприятие речь идет об инвестициях порядка 200-300 000 долларов за типовой набор функций: финансы, снабжение, сбыт, производство, логистика. На их внедрение уйдет от шести месяцев до одного года. В табл. 3.2 приведены ориентиры для выбора системы. Главная метка — количество одновременно работающих с системой пользователей. Также необходимо учитывать объем обрабатываемых документов. Например, компания является депозитарным центром. При небольшом количестве пользователей (20-30, казалось бы, «легкая» система потянет) ей приходится обрабатывать большие массивы данных (несколько десятков тысяч документов в месяц). В таком случае руководство должно принять решение о внедрении отнюдь не «легкой» системы. В таблице упомянуты и «средние» системы. Яркими представителями данного класса являются Microsoft Dynamics NAV и АХ. Средние сроки их внедрения — от шести до 18 месяцев с общим бюджетом 500—1 500 000 евро. В ряде случаев внедрение средней системы по бюджету может быть сопоставимо с внедрением «тяжелой». Обычно такое происходит в очень крупных холдингах, решивших устанавливать не единую централизованную систему, а нескольких систем среднего размера в каждом подразделении. В этой же таблице упомянут «сайзинг» — документ, гарантирующий работоспособность системы при требуемом количестве пользователей и учетных событий. Его подписывает производитель системы. Комплексная или сервисы Другой аспект выбора — комплексная система или сервис. Сразу хочу предостеречь относительно второго варианта: сколько у вас будет сервисов, столько будет и разных поставщиков; под 9 3 39 каждого надо организовать свой процесс внедрения. Естественно, такой проект будет значительно меньше проекта по внедрению комплексной системы. Как определить, является ли интересующая вас система популярной, распространенной и востребованной? Кроме прямых признаков — известность, представительство в стране, положительные отзывы прессы, — есть один косвенный: компания, поставляющая бизнес-приложение, сама не должна заниматься внедрением. Для этих целей существует широкая сеть партнеров, консалтинговых компаний и системных интеграторов. Но для развития своего продукта компаниипоставщику необходимо иметь в своем арсенале экспертов. Их разработки будут опережать потребности клиентов на два шага вперед. И совсем неплохо заручиться поддержкой таких людей. То есть договор о внедрении вы будете заключать с консалтинговой компанией, а контроль его качества может осуществлять разработчик. Это, конечно, дополнительные расходы, но они часто окупаются. Неудачное же внедрение и отсутствие единой системы контроля может привести к ситуации, когда вы не знаете, кому предъявить претензии. Если это — плохо настроенная программа, вроде, виновны консультанты, а за недоработанный функционал системы, по сути, ответственность лежит на поставщике. Чтобы не гадать, нужен единый контроль качества разработчика. По крайней мере, он гарантирует надлежащее исполнение партнером всех процедур и правил по настройке установленной у вас системы. С чего начинать выбор Распространенный вопрос: с чего начать выбор? Многие успешные компании сначала определяются с системой и только потом — с партнером по внедрению. 4 40 Ни в коем случае не полагайтесь исключительно на мнение компании о конкурентах - оно может оказаться необъективными. На этапе выбора системы надо отсмотреть продукты основных разработчиков, представленных на рынке. Этот процесс можно разделить на несколько волн. Первая волна — знакомство с функционалом существующих систем. Вы решаете, какая вам нужна система: комплексная или сервисы, «тяжелая» или «легкая». На этом этапе могут быть предварительные просмотры, консультации, но не детальный анализ функций и форм систем. Цель первой волны — определиться с размером будущей системы. Глядя в формы ввода, вы не сможете этого понять. Здесь, скорее, нужны экспертные мнения. Весьма полезны здесь будут, например, системные интеграторы, которые внедряют системы и «легкого», и «тяжелого» классов. Не рекомендуется опрашивать тех, кто внедряет лишь одну «весовую» категорию систем — каждый будет доказывать свою точку зрения. Кстати, если точка зрения одного из интеграторов доказывается прагматичным ответом, что, например, внедрение больших систем приносит больше денег, это нормально. Такой ответ, кроме всего прочего, свидетельствует об открытости и, вероятно, успешности вашего собеседника. Если системный интегратор внедряет системы обоих классов, неплохо уточнить, какое у них соотношение в общем объеме бизнеса. Самые известные производители «тяжеловесных» систем — SAP (продукт «SAP/R3») и Oracle (продукт «Oracle E-Business Suite»). Есть системы и для среднего бизнеса — «Microsoft Dynamics АХ» и «Microsoft Dynamics NAV» от Microsoft, «SAP Business One» от SAP и «Oracle JD Edwards» от Oracle. Бесспорным лидером для оптимизации малых и средних предприятий является «1С» и фирмы, которые занимаются ее внедрениями (их больше тысячи). Итак, в ходе первой волны вы определяете, какого класса система вам нужна. 1 4 41 Вторая волна — выбор внутри класса. Ни в коем случае не сравнивайте «легкую» систему с «тяжелой» — она будет уступать почти по всем параметрам. А в итоге проиграют обе. Класс системы есть. Дальше вы вступаете в более плотные переговоры с поставщиками. Вы спросите: «А где их взять?» На самом деле количество поставщиков ограничено. Так, перечень ERP-систем исчисляется максимум десятью позициями, включая «легкие» и «тяжелые» варианты. Поэтому, выбрав «весовой» сегмент, вы сужаете круг общения до трех-четырех разработчиков. Важное замечание. Некоторые системы честно или нет могут оказаться одновременно в обоих сегментах. Что значит «честно»? Есть предприятия, где количество работающего в системе персонала превышает 100 человек или вообще измеряется сотнями, и система (допустим, Microsoft Dynamics NAV, бывший Navision) справляется с такой нагрузкой. Раз она может работать с сотней пользователей, несколько десятков ей ни по чем. Это называется честный перехлест. А нечестный — это когда поставщик-разработчик «насильственно» позиционирует продукт несоответствующего вашим потребностям размера. Например, если поставщик «тяжелой» системы сильно демпингует, чтобы выполнить квартальный план. Это плохо для вас, потому что как бы мало вы ни заплатили за лицензии, впоследствии вам придется платить за сопровождение превосходящей ваши реальные масштабы системы и за работу консультантов по высоким ставкам. Вообще во всем IT-мире затраты на внедрение системы в разы превышают суммы на ее приобретение. Другой случай — производитель малой системы утверждает, что его система запросто сможет работать с большими объемами данных и внушительным количеством пользователей. Такую информацию нужно просто проверять. Фирмы, использующие эти системы, на себе испытали все тяготы внедрения. Если вы найдете по каждому из рассматриваемых вендоров, минимум, двух счастливых клиентов, значит, и вендор говорит правду, и система вам подходит. 2 4 42 Еще один важный критерий при выборе системы — совместимость и гибкость. На первый взгляд это технологические нюансы, но достаточно простой бизнес-логики, чтобы понять: система должна быть совместимой с другими системами, которые уже используются на предприятии или, возможно, будут применяться в будущем. Есть такое понятие — «открытость». Выбранная система должна быть открыта — для взаимодействия с себе подобными (основными, популярными, распространенными в стране и мире системами) и для доработок. Другое важное понятие — «гибкость». Под гибкостью можно понимать очень абстрактные и вполне конкретные вещи. Когда мы с вами говорили об отчетах (динамические отчеты и другие), речь как раз шла о гибкости системы — возможности пользоваться ею самостоятельно, без привлечения ITспециалиста; изменять функциональность; подстраивать систему под свою фирму. Конечно, такой процесс не бесконечен. Но все, что касается работы с данными, их анализом и получением необходимых для пользователя сведений, завязано на гибкость системы: чем быстрее она может предоставить требуемую информацию, тем она гибче. Конечно, выбираемое бизнес-приложение должно быть совместимо с той операционной системой, которую вы используете на всех компьютерах. Не сегодняшний день самой распространенной ОС является Windows. Хотя, возможно, вы используете открытые технологии, например, один из деривативов системы класса Linux. Надо четко понимать: система не должна привести к тотальным изменениям, а значит, — дополнительным и порой крупным инвестициям в ITинфраструктуру, которая уже имеется и эксплуатируется. Не забывайте и о том, что в нашем высокотехнологичном мире выживает тот, кто может наладить информационный обмен не столько внутри своего предприятия, но и со своими партнерами, клиентами, поставщиками. Контрольный пример Окончательный выбор мы рекомендуем делать в режиме тендера. Так вы сможете сопоставить множество необходимых 3 4 43 вам системных требований. Но! Очень важно, чтобы основные функциональные потребители будущей системы (например, линейные руководители подразделений, чья деятельность будет автоматизироваться) оценили функциональность системпретендентов. Чтобы детальный «просмотр» оказался продуктивным, и у вашей рабочей группы была возможность сопоставлять более-менее одинаковые факторы, необходимо разработать контрольный пример. В нем описывается один из сквозных бизнес-процессов вашей компании или его упрощенный прообраз. Следует прописать даже минимальный набор классификаторов и цифровые значения регистрируемых документов. Таким образом, консультанты будут вынуждены «преднастроить» свои системы для показа вам. Все это делается, чтобы по ходу презентации системы они четко следовали разработанному в примере сценарию. Кроме того, вы сможете видеть «свои» данные, а не цифры и названия товарных единиц отвлеченного типового примера. Запасной план Говоря о волнах, мы подразумеваем некую промежуточную фазу и возможность возврата к более раннему этапу. Что имеется в виду? Вы выбрали сегмент — необходима «тяжелая» система. Из имеющихся на рынке отобрали лучшую. Затем следует второй этап — выбор партнеров. Система должна быть хороша не только потому, что она функциональна, представлена в России и локализована (есть много примеров удачных внедрений и счастливых клиентов), но и потому, что в следующей фазе, когда вы станете выбирать консультантов, у вас будет широкий выбор. Или их будет немного, но все они — успешны, и все их внедрения заканчивались положительно. Данный критерий необходимо выявить еще на первой волне. Переходя к решению вопроса с консультантами, не стоит сжигать все мосты. Вы можете остановиться на двух системах, удовлетворяющих вашим критериям, либо выбрать одну основную и вторую «запасную». На этапе выбора интегратора вы можете столкнуться с тем, что ни один консультант не в силах гарантировать качественное внедрение 4 44 вашей системы-лидера. Тогда задействуется план Б, и вы анализируете итоги работы консультантов, внедряющих «запасную» систему. О том, как выбрать поставщика услуг по внедрению системы управленческого учета, мы расскажем в следующем разделе. ВЫБОР СИСТЕМЫ Секреты покупки информационной системы Как не купить слона в мешке и распознать типичные уловки недобросовестных sales-менеджеров? Как клиент выбирает ERP-систему? Всегда ли задает те вопросы, которые действительно важны? Что чаще всего упускают из вида при общении с консультантами, рассмотрении коммерческих предложений? Так же, как и любую другую услугу или продукт. Есть только несколько нюансов. Сам продукт (ERP-система) является виртуальным, а услуги по его настройке непросто измерить для формализованного качественного сравнения («длиннее, легче, надежнее»). Как следствие – при выборе продукта колоссальным фактором является сила бренда ERPсистемы. При выборе услуг бренд тоже немаловажен. Но на первый план выходят навыки и компетенция людей, эти услуги представляющих. Задача таких сотрудников - прежде всего, показать себя как экспертов, а потом представить свою компанию как подрядчика. Другими словами - формально оценить продукт и услуги непросто, а чаще всего и не надо. Как же тогда выбирать? Внутренний выбор обычно делается на основании эмоций («они мне больше понравились») по итогам первых встреч с потенциальными поставщиками услуг. После чего под выбор выстраивается «доказательная база» - у кого больше экспертиза, лучше команда, выше партнерский статус. Но даже 5 4 45 если ваш выбор основан на эмоциях (кто сказал, что это плохо?) важно убедиться, что: 1. Вы покупаете именно тот результат, который вам нужен. 2. В полном объеме. 3. В обещанные сроки и надлежащего качества. 4. Сравниваете сопоставимые по уровню и качеству продукты/услуги. В процессе переговоров многие вопросы по разным причинам не проговариваются, а додумываются: например, когда клиент интересуется стоимостью проекта, на этот вопрос редко услышишь конкретный ответ. О стоимости проекта говорится только в связи со ставками занятых в нем консультантов. Или другой пример. Заказчик хочет понять, насколько быстро в системе можно доработать тот или иной функционал. Вместо часто задаваемого пространного вопроса о «гибкости» лучше конкретизировать: сколько времени требуется на разработку одного отчета в данной ERP-системе? В ответ могут последовать сравнимые показатели – час, день или неделя. Очевидно, что чем меньше времени тратится на разработку отчета, тем выше «гибкость» системы. Иногда чересчур ловкие продавцы пользуются невнимательностью клиента. Например, такому продавцу стал известен бюджет клиента на проект или предложение конкурирующей фирмы. Что может сделать недобросовестный продавец для предоставления более выгодных, на первый взгляд, коммерческих условий? Допустим, в коммерческом предложении на проект ограничить объем разработок тремястами человеко-часами. Если уловку не заметят, проект может просто не дойти до стадии опытной эксплуатации: 300 рабочих часов закончатся, а готовой системы еще не будет, и клиенту выставят счет за дополнительную работу программистов. Что выходит? Клиент ожидает получить систему «под ключ» по фиксированной цене, а вместо этого имеет 300 часов работы программиста. Почувствуйте разницу... Иногда продавцы уговаривают клиента подписать договор о работах первой стадии, результатом которой является выработка технического задания 6 4 46 (ТЗ). Это еще одна уловка: ТЗ компания пишет для себя, под ту систему, которую интегратор предлагает клиенту. ТЗ, созданное одной компанией, не может быть потом реализовано другой без проведения дополнительных согласований. Таким образом, клиент вынужден продолжать работать с тем, кто создал ТЗ - ведь он уже вложил деньги в его разработку! Для клиентов важно, чтобы все прайс-листы на оборудование и программное обеспечение были составлены по одной и той же системе: в одной валюте, с одинаковым подходом к НДС (везде включен или не включен). Также заказчик должен быть уверен, что сделанное ему предложение включает все коммерческие (транспортные, командировочные и т. п.) расходы. Еще один важный момент связан с внедрением систем, стадией опытной эксплуатации. Минимальный срок опытной эксплуатации крупной системы - полтора месяца, оптимальный два с половиной. Для полной уверенности проследите, чтобы в ТЗ была указана ее продолжительность (не менее двух с половиной месяцев). Если ERP-системы сопоставимы, их надо по какому-то принципу оценивать. Трудно сказать, у кого из брендов - лидеров первой пятерки системы сильнее. У каждого есть свои преимущества, пути развития и способы привлечения клиента... SAP и Oracle- сопоставимые системы, но со своими нюансами. Что будет определять выбор из двух сопоставимых по классу систем? Ясно, что не бренд, а конкретные плюсы, имеющиеся у каждой системы, которые подходят клиенту. Давайте подробнее остановимся на ситуации, когда клиенту нужно выбрать одно из нескольких конкурирующих предложений. Здесь мы бы говорили не о брендах, а собственно о продуктах, самой компании-вендоре и о внедренце - как они развиваются, на что тратят деньги, как думают о будущем. На самом деле правильный выбор во многом определяет состав конкурсантов. Важно сравнивать продукты одного уровня. Это 7 4 47 касается и выбора компании-консультанта. Почему стоимость импортных систем существенно отличается друг от друга? Все системы условно делят на четыре класса: тяжелые, средние, коробочные и... самописные. Делят по объему стандартного функционала и производительности. Например, есть такой критерий, как поддержка процессного типа производства (планирование, расчет затрат) - это обеспечивают не все системы. Критерием также может быть количество пользователей, которые одновременно могут работать в системе: только часть современных IT-решений может обеспечить одновременную работу в системе нескольких тысяч пользователей. Западные аналитики (Gartner, IDC) написали множество отчетов для обоснования, почему одна система «более ERP», чем другая. Однако изучение отчетов занимает много времени. Тем более, что практически у каждого вендора есть отчет, из которого следует, что именно его продукт - самый лучший. Как в такой ситуации определить, к какой категории относится продукт? Самый простой способ, как ни странно, - спросить о продукте у его конкурентов. Если не хотите спрашивать, можно воспользоваться другим способом. Этот вариант основывается на утверждении, что рынок (другие покупатели ERP) до вас уже сегментировали ERP-системы на классы. Результатом такого сегментирования является... стоимость. Утверждение спорное, но на практике работает. Уточните стоимость одного рабочего места в системе. В тех случаях, когда производитель отдельно лицензирует пользователей и функционал, запросите информацию о средней стоимость рабочего места. После этого вы легко сможете распределить ERP-системы по нескольким сегментам. Теперь можно сравнивать, особо не беспокоясь, что выбор идет между системами разных классов. Еще можно сформулировать детальные (до операций в системе) функциональные требования к ERP-системе. Попросить вендора отметить, что можно отнести к стандартным опциям, что - к нестандартным, а что – к «требует доработок». Полученную таблицу, при желании, можно прикрепить к договору. И если какой-то функционал до этого был стандартным, а в техническом задании стоит, что он «требует 8 4 48 доработок», возникает вопрос. Но это субъективно, а цена в прайс-листе объективна: здесь рабочее место стоит столько, а здесь - столько; это разные классы систем. По аналогии с автомобилями: производители машин придумали их классификацию для того, чтобы потребители сравнивали сравнимые вещи. Представим, что клиент хочет оценить один и тот же проект с использованием сопоставимых ERP-систем. Получил два предложения: в одном стоимость – 100 000 у.е., во втором - 200 000 у.е. Сроки исполнения проекта совпадают. Где же «собака зарыта»? Есть несколько вариантов: 1. Вы сравниваете консалтинговые компании с разным уровнем рентабельности или квалификации. Чтобы это понять, запросите ставки (стоимость одного человеко-часа) и сравните со средними ставками по рынку компаний, специализирующихся на данной ERP-системе. 2. Консалтинговые компании сравнивают разные проекты. Составьте документ с требованиями к объему автоматизируемого функционала и списку ваших компаний (подразделений), которые будут вовлечены в проект. Предоставьте возможность всем конкурсантам сравнивать одинаковые требования. 3. Вы покупаете результат разной степени готовности (вспомним про случай с ограничением объема доработок системы). Уточните у конкурсантов, что будет являться результатом проекта и в каких случаях стоимость проекта может увеличиться. 4. Вам «продают» разное количество ресурсов. Запросите трудоемкость проекта (например, в человеко-днях) при условии 100% занятости. Чудес не бывает. Если на проект по одинаковому продукту (или равных по сложности системах) вам ангажируют в два раза меньше ресурсов, чем в аналогичных предложениях, есть повод задуматься. Скорее всего «недостающих» консультантов или программистов вам предложат использовать за счет внутренних ресурсов компании. 5. Накладные расходы. Конечно, они редко составляют 100% разницы (если только ваш проект не на Дальнем Востоке), но все равно уточните, входят ли они в стоимость. 9 4 49 Для оценки ставок и трудоемкости проекта клиент может составить сравнительную таблицу выполнения работ разными консультантами: просчитывается работа каждого сотрудника на проекте. Получаем общую человеко-часовую загрузку по всем стадиям проекта - N. Поделив итоговую стоимость на загрузку, получаем среднюю ставку, соотносим с ранее озвученными ставками на встречах и делаем выводы. Если ставки совпадают, консультанты честны. Фирма, которая нацелена на выстраивание долгих отношений с клиентом, готова доходчиво объяснить, из чего складывается стоимость проекта: вот эта цифра у нас в оферте не равна итоговой стоимости проекта потому, что не все моменты могут быть учтены на предварительной стадии. Она может быть увеличена или уменьшена на основании реального хода проекта. Расчет стоимости проекта по fixed-price, с одной стороны, позволяет в большей степени учитывать риски, но он и приводит к удорожанию в среднем на 20%. Клиентам, у которых нет опыта внедрения систем и обученной команды, лучше запрашивать стоимость, рассчитанную по fixed-price, но помнить, что они при этом переплачивают за соответствующие риски внедренцев. Кроме того, клиентам можно посоветовать с самого начала работать с компанией-консультантом по следующему правилу: вы должны видеть менеджера проекта и консультантов, которых нанимаете. Требуйте участия в переговорах тех людей, которые будут потом работать на проекте со стороны исполнителя. Чтобы склонить вас к выбору именно этого партнера по внедрению, вам выделят лучшие кадры. Но зачастую проект реализуют не те люди, которых вам представили как будущих участников проекта. У одной компании на рынке консалтинга была такая традиция: приходит человек, гарантирует успешный проект со всеми учтенными пожеланиями клиента, но в контракте фиксируется лишь часть обещанного. А потом появляется менеджер проекта и говорит такую фразу: «Все, что вам обещал мой коллега до этого, забудьте. Теперь слушайте, что мы будем делать на проекте на самом деле». Очень важно, чтобы человек, который вам что-то обещал, потом принимал участие в проекте. 5 50 Еще такой момент: нужно постараться объективно отнестись к рекомендациям клиентов. Если клиент говорит: «У нас все было хорошо, проект шел гладко, и сейчас у нас тоже все отлично» – это повод задуматься, потому что идеальных внедрений не бывает. Всегда есть шероховатости. Если клиент говорит: «У нас сейчас все нормально, но на этапе запуска была определенная проблема, с которой компания-консультант благополучно справилась», – такой рекомендации веришь. Бывает, что на один проект привлекаются различные подрядчики, выполняющие отдельно взятые работы. Как в этом случае минимизировать риски? Клиент минимизирует риски в том случае, если генеральный подрядчик предлагает и услуги по внедрению, и само оборудование. Договор заключается между подрядчиком и клиентом; никаких отношений с субподрядчиками клиент не имеет; ответственность за их работу несет генеральный подрядчик. Советуем клиенту при переговорах придерживаться такой линии: «Я плачу вам за генподряд, что увеличивает стоимость работ, например, на 10%. Вам решать, кого из подрядчиков нанимать. В любом случае вы отвечаете за весь проект». Вопрос конечной ответственности за проект возникает и тогда, когда проект ведется силами нескольких департаментов одной консалтинговой компании. Например, у нас есть несколько клиентов, где запущены два или более проектов одновременно: внедрение учетной системы и системы бюджетирования, или учетной системы и системы управления складом. Нужно понимать, как эти два проекта интегрировать, кто будет осуществлять координацию и соответственно - нести ответственность. Начинаться два проекта могут в одно время, а заканчиваться – в разное. Например, один проект заканчивается, а интеграция с системой, разрабатываемой в рамках второго проекта, еще не произведена. Команда довольна – она подписала акт ввода в промышленную эксплуатацию, а клиент недоумевает: 1 5 51 «Ребята, я же подписывал договор с одной компанией, вы должны были продумать, как два ваших проекта будут взаимодействовать между собой, и кто – за все отвечать. Я только поэтому заключал с вами договор». Если вспомнить классику отечественной сатиры, ситуация – как в известной миниатюре Аркадия Райкина про пиджак. «К пуговицам претензии есть? - Вроде, нет. А проблемы есть». Клиент должен настаивать на одном менеджере-кураторе обоих проектов, который и будет отвечать за результат работы всей компании. Еще хотелось бы поговорить о роли вендоров в проектах. Наиболее часто встречаются три типовые схемы взаимодействия с вендорами: когда их консультанты участвуют в проекте на субподряде, когда сам вендор выступает генподрядчиком или когда консультанты вендора подключаются на последней стадии проекта, приезжая и проверяя уже установленное оборудование, осуществляя контроль качества. Бывает, что клиент сам напрямую привлекает вендора к проекту ради скидки. В таком случае советуем это делать до выбора основного партнера – консалтинговой компании. Тогда клиент может разделить риски и ответственность за проект с вендором. Проектную команду, составленную из специалистов консалтинговой фирмы и заказчика, часто называют одним из условий успешности проекта. Но это одновременно и риски – если нечетко определены зоны ответственности и лицо, которое несет за проект конечную ответственность. Что делать клиентам? Проект, как правило, является совместной работой единой команды со стороны заказчика и со стороны исполнителя. Случается, исполнитель берется делать все сам. Но это трудный вариант. С самого начала нужно проговорить, кто какие работы и на каждой стадии проекта делает, за какие результаты отвечает. Кстати, это очень редко фиксируется, тем более на стадии коммерческих предложений. Поэтому опытные клиенты просят прислать им не коммерческое предложение, а договор, а лучше бы и то, и другое 2 5 52 с приложениями к нему, в которых четко расписано, что делает на каждом этапе представитель заказчика и за что он несет ответственность. В договоре должно быть как можно больше конкретики: о чем договорились, как мы работаем, как делим функции, кто за что отвечает, сколько стоит день нашей работы, сколько человек работает на проекте. Нужно прямо в договоре отметить «контрольные точки» по проекту, зафиксировать стадии с перечнем задач, итоговых документов и критериев завершения. Чем подробнее договор, тем потом легче работать и меньше конфликтов и неприятных сюрпризов. Для серьезного бизнеса, тем более для публичного, ценность ERP-системы еще и в том, что она не зависит от консалтинговой компании, которая ее поддерживает. Мировые бренды остаются в моде. Как же клиенту противостоять магии бренда? А зачем противостоять? Для публичной компании ERPсистема от транснационального вендора – это гарантия прозрачности и стабильности. В таких организациях из-за ухода отдельного человека (или отдела), поддерживающего систему, работа не остановится. Еще важный момент возникает при проверке отчетностей аудиторами: им гораздо легче это делать, когда они имеют дело со знакомой системой учета. Правда в том, что надежная система от известного вендора снижает риски. Собственный программист может уволиться. Что в этом случае делать с самописной системой, которую он разрабатывал и поддерживал? Маленькая компания-разработчик может закрыться или перепрофилироваться. Магия брендов еще не достигла своего апогея. Она с каждым годом будет все больше. Логика выбора клиента зачастую такова: «Да, вы - классная компания, у вас классный продукт, но как вы называетесь? АСУ «Склад» версия 1.1? Мы вам верим, но есть решение X от мирового лидера Y». Надежность, известность бренда много значит и для тех компаний, которые внедряют эти решения. При выборе между 3 5 53 небольшой компанией, при всем ее потенциале и преимуществах, предпочтение отдается тем, у кого больше опыта и больше выполненных проектов. Клиенты говорят: «Мы выбираем их. Да, это дороже, но надежнее». До недавнего времени было модно все выстраивать в одной системе. Самой главной приманкой для клиентов было: «Что у вас за зоопарк систем? В бухгалтерии одна, в логистике - другая. Проблема при интеграции, данные пропадают. Огромный ИТотдел. Короче, вам нужна единая система, одна база данных, где все интегрировано». То есть если систему нужно было расширять, то за счет соответствующих модулей от того же вендора, а не специализированного решения. Сегодня эта мода уходит. Кругозор клиентов расширяется. Становится понятно, что иногда правильнее предпочесть стратегию best-of-breed (лучшие системы в своем классе) стратегии единой системы. Всегда понятно, что в специализированном решении больше нюансов. Например, клиенту, внедряющему систему Oracle для основных операций в области розничной торговли, для операций на распределительном центре можно предложить Manhattan WMS – отличный продукт в своей области в мире. При этом клиент понесет дополнительные траты на интеграцию двух систем. Гораздо важнее названия системы то, насколько она хорошо внедрена, а также какие результаты реально достигнуты в ходе проекта. Многие компании задумываются о повышении капитализации и готовятся к выходу на публичный рынок. Например, есть миф, что внедренный в компании SAP повышает капитализацию. Он идет от того, что заложенные в систему шаблоны бизнес-процессов понятны западным менеджерам. Каждый клиент ставит перед консультантами разные задачи и оценивает их работу по разным критериям, исходя из особенностей его бизнеса. Поэтому всегда важно, чтобы у клиента и консалтинговой компании, работающей над созданием его информационной системы, сформировалось взаимное доверие и единое понимание целей проекта. Тогда сотрудничество становится плодотворным, а проект – успешным. 4 5 54 Глава 1.4. Выбор поставщика услуг по внедрению приложения Д. Новоселов: «Систему оперативного учета мы внедряли собственными силами. Беда такого внедрения в том, что задачи выстраиваются постепенно и последние могут полностью или частично противоречить более ранним. Прелесть же любого консалтингового проекта состоит в том, что сначала пишется техническое задание, где согласовываются все нестыковки, а потом начинается само внедрение. У нас возникла проблема, когда на двух заводах внедрили одно и то же бизнес-приложение, но, по сути, — две разные системы. Это мешало получать объективные данные для управленческого учета. То дебиторку с кредиторкой на одном контрагенте не свести, то еще чтонибудь. Даже в рамках одного завода. Конечно, часть вопросов сегодня решена, но не все. Этот груз — сэкономленных денег на внедрении учетной системы — мы тащим за собой не первый год». Поставщик услуг или консультант должен разговаривать с вами «на одном языке», то есть понимать вашу отрасль, работать с ней не первый год, иметь доказанные истории успеха в аналогичных компаниях. Первыми в списке потенциальных консультантов будут те, кто внедрял системы вашим конкурентам. Если вы уже определились с приложением, проведите собственный анализ интернет-публикаций, чтобы выбрать наиболее активных и успешных консультантов, внедряющих данную систему. Кроме того, производитель может порекомендовать вам одного или нескольких из своих партнеров. Итак, список претендентов на внедрение системы управленческого учета выглядит следующим образом: 1. Рекомендации коллег по цеху. 2. Интернет-публикации. 3. Рекомендации вендора. Полезный совет может дать и ваш аудитор или управленческий консультант, которые помогали поставить 5 55 управленческий учет. К их рекомендациям стоит прислушаться. Ведь если партнерство интегратора и управленческого консультанта давнее, между ними, скорее всего, есть взаимопонимание рабочих групп; они разрабатывают понятные друг другу документы. А вы выигрываете от их совместной работы. Большой, но дорогой Есть несколько коротких советов по выбору консультантаинтегратора, которые мы просто приводим списком: 1. Выясните, какое место в бизнесе интегратора занимает внедрение интересующей вас системы. Если консультанты лишь вчера начали внедрять нужную вам систему, это не всегда плохо. Возможно, интегратор имеет неплохой опыт внедрения других аналогичных систем, видит перспективность выбранного вами продукта и приложит максимум усилий, чтобы сделать ваш проект, так как от его успешности будет зависеть перспективность всего нового направления деятельности. К тому же у вас есть возможность получить скидку. 2. Высшее руководство фирмы-интегратора должно быть вовлечено в проект и знакомо с руководством вашей компании еще до подписания контракта. 3. Постарайтесь выяснить квалификационный состав подразделения, которое будет внедрять у вас систему: сколько всего человек, сколько среди них менеджеров проектов и консультантов, есть ли стажеры. Выясните среднее количество специалистов на проекте. Так вы сможете определить степень загрузки консультантов по вашему направлению. Если она — в районе 70%, значит, дела на данном бизнес-направлении интегратора идут хорошо. 4. В команду по внедрению должен входить системный архитектор, обладающий опытом работы именно с вашим приложением. При сложных комплексных внедрениях менеджер проекта не должен совмещать в себе должность архитектора. 5. Каждый вендор присваивает своим партнерам различные статусы, подтверждающие их успехи при реализации и 6 5 56 внедрении соответствующих систем. Чем выше статус рассматриваемого вами интегратора, тем больше шансов получить качественное внедрение. 6. Наличие сертифицированной системы управления качеством выполняемых услуг сегодня стало стандартом отрасли ИТ-интеграции. 7. Желательно, чтобы менеджер вашего будущего проекта имел действующий сертификат профессионального сообщества менеджеров проектов (например, PMI). 8. Наличие отраслевого решения, максимально соответствующего вашему бизнесу, удешевляет проект внедрения при незначительном удорожании стоимости лицензий. 9. Если вам необходимо послепроектное сопровождение, интегратор должен иметь выделенную службу поддержки, работающую с выбранным вами бизнес-приложением. 10.Методология внедрения интегратора должна быть не только сертифицирована в соответствии с международными стандартами (например, ISO 9001:2000), но и соответствовать методологии вендора. Конфиденциальность Многие боятся, что приход консультанта на предприятие приведет к раскрытию ноу-хау. Если, например, вы занимаетесь строительством, то консультант, работающий со строительными компаниями, может неким образом распространить ваши бизнеспроцессы, уникальные и разработанные вами классификаторы (скажем, статей затрат и доходов) на других своих клиентов. Речь идет даже не о недобросовестности — с первых шагов консультанта на предприятии вы должны подписать с ним договор о конфиденциальности. Просто невозможно сделать более-менее оправданное, мотивированное и качественное коммерческое предложение, не узнав о вашем предприятии как можно больше. Чтобы застраховать себя от распространения извне вашей внутренней информации, следует оформить соглашение о конфиденциальности. Тяжело перекрыть доступ консультантов к настроечным данным — справочникам, типам, коэффициентам, отчетным 7 5 57 формам и т. п. Но закрыть для них документы и промышленные сведения можно. Делать это нужно перед началом опытной эксплуатации (см. главу 3.6 «Методология внедрения»). Это вполне укладывается в суть передачи системы: вы эксплуатируете систему, которая принадлежит вам. Свободный доступ к ней должен быть лишь у вас, чтобы не размывать ответственность за то, что с системой происходит, между вами и консультантом. Впрочем, ноу-хау может уйти за пределы компании и другим, «непрямым», путем. Если вы работаете с консультантом, который еще не имеет богатого опыта в вашей отрасли, то многое из того, что он для вас сделает, может послужить основой для создания отраслевого решения. Или если такое решение уже есть, а вы — достаточно прогрессивный игрок, настройки его существенно обогатят. Этот вопрос, конечно, сложный. Многие пытаются заключить соглашения, которые прямо запрещают консультанту работать с вашими конкурентами. Некоторые даже их перечисляют в договоре на консалтинг и закрепляют вето на определенный срок. Такой подход малоэффективен. Во-первых, сильно ограничить свободу консультанта вы если и сможете, то лишь за большие деньги. Консультанты живут отраслевыми знаниями и решениями, работой с крупными развивающимися компаниями. Для них принять ваш запрет, — значит, ограничить свой будущий бизнес и потерять интерес к работе, например, в сфере металлургии. Соответственно снижается и интерес к вашему контракту. Е. Плаксенков: «Я не уверен, что найдутся люди, которые смогут, даже получив полное описание проекта, в достаточно короткие сроки воспроизвести у себя то же самое. МСФО известны всем профессионалам. Стандарты PMI доступны каждому. Планы счетов написаны не иероглифами. Кодификаторы очевидны для тех, кто управляет процессами. Но на все нужно время и мозги. А люди всегда «перетекают» между компаниями: сегодня работают у консультантов, завтра — в девелоперском бизнесе и консультируют уже по другому 8 5 58 направлению и в другой компании. Все полученные знания они уносят с собой. Поэтому конфиденциальность нематериальных активов условна. Это знание, которое живет своей жизнью. Я не хочу тратить время на раздумья: «Кто у нас это украл?». Важно двигаться вперед». Интерес консультанта Многие, конечно, могут спросить: «А причем тут интерес?» Это вещь не юридическая. Все, что нам нужно прописать в контракте, мы пропишем и будем требовать с исполнителя результат. (Мы касаемся, пожалуй, самой больной темы при автоматизации управленческого учета.) К сожалению, на стадии составления контракта максимально полно прогнозировать и результат, и инвестиции, а зачастую — и сроки невозможно. Случай с недобросовестным исполнением сторонами своих обязанностей в расчет не берем. Речь идет о естественных преградах на пути к точному прогнозированию объема инвестиций и итогов проекта. В начале проекта заказчик и консультант находятся в одинаковом неведении относительно того, что будет по окончанию проекта. Сроки проектов всегда немалые — даже внедрение «легкой» комплексной системы сегодня занимает полгода. Это достаточно серьезный срок для стремительно развивающихся фирм. Вы не всегда можете предполагать, как изменится ваш рынок, продукт, бизнес, видение компании. И если меняется ситуация, меняется и отношение к договору и проекту, который вы реализуете. С консультантом происходит то же самое. Появляются новые технологии, корректируется позиционирование внедряемой системы, возникают новые функции и отмирают старые. От всех факторов не застрахуешься. Все это неминуемо ведет к уменьшению рамок проекта по мере приближения к его окончанию и росту инвестиций в него. Конечно, это не приговор. Никто не говорит, что когда приходится платить больше за ремонт в конце (хотя вы плотно занимались ремонтом и контролировали процесс, высказывали 9 5 59 пожелания, меняли их и радовались, а ремонтная бригада быстро все выполняла), вы не рады дополнительным инвестициям. Но вы их делаете осознанно, понимая, за что платите. Увы, это — реальность, ее не избежать. Пилотные проекты Тупиковым является вариант, когда вам предлагают так называемый пилотный проект, результатом которого становится техническое задание. Казалось бы, идея — красивая: вы страхуетесь от недобросовестно изготовленной системы и от недобросовестного консультанта; получаете техническое задание, которое потом можно предъявить другому консультанту, чтобы он внедрил другую систему. Все замечательно, но в жизни так не бывает. Любой консультант все равно делает техническое задание, если и не ориентированное на конкретную систему или хотя бы класс, то обязательно соответствующее его собственным стандартам и форматам. В большинстве случаев при смене консультанта новый обязательно попросит изменить ТЗ. При этом потребуется новое обследование, интервьюирование ваших специалистов и т.д. То есть сценарий «проект, ТЗ, потом — все остальное» увеличивает стоимость проекта в целом. В этой и предыдущих главах мы намеренно подробно не рассматриваем вопрос составления так называемых опросников или контрольных листов. Примеры тендерных опросников по системам и по выбору поставщика услуг приведены в приложениях. Референтный визит Лучший способ проверить качество поставщика услуг — позвонить нескольким его клиентам. Желательно тем, кто использует предлагаемое им решение давно. Правда, с тех пор, как они начали пользоваться системой, изменились ее версии да и сам бизнес клиента. Тем не менее, если вы услышите абсолютно восторженный ответ, он должен вызвать подозрения. Идеально, если он будет приправлен ложечками дегтя. «У нас были проблемы на стадии создания технического задания, но консультант убедил нас, что мы не должны менять цели 6 60 внедрения по ходу проекта. Он пошел нам на встречу и сумел гибко подстроиться к предложенным нами изменениям. Благодаря этому мы получили проект в срок и надлежащего качества», — это объективный ответ, который вполне можно расценить как положительную референцию. Если вы слышите отрицательный отзыв, надо по возможности разобраться в его причинах. Часто бывает, что виноват сам клиент. Возьмем самый простой случай — у компании меняется спонсор, двигатель, менеджер проекта. Любой проект — это воля какого-то человека. Даже если она выражена в нескольких словах, должен появиться некто, кто скажет: «Я отвечаю за вложение этих миллионов долларов в повышение эффективности нашей компании». Что происходит, когда такой человек уходит? Даже если миллионы потрачены не впустую и все работает, приходит новый сотрудник. Ему необходимы новые достижения и принижение успехов предшественника. В таких случаях компания, используя внедренную систему, может не дать положительных референций о ней и о консультантах. Поэтому ваша задача — выяснить реальную обстановку. Эмоциональная составляющая важна, но по большей части в начале разговора: «Довольны ли вы работой консультанта? Устраивает ли система?» и дальше вы углубляетесь в конкретику: • Используют ли они эту систему? • Кто использует? Сколько всего пользователей? • Сколько человек поддерживает систему внутри компании? • Какие еще системы используются на предприятии? • Как долго длился проект? Совпал ли срок его внедрения с планом? • Были ли отклонения в бюджете? • Вы подстраивали БП под систему или наоборот? И т.п. Цифры всегда говорят сами за себя. Эмоциональный окрас отзывов зачастую не дает реального представления о положении дел. Вернемся к референтному визиту. Желательно побеседовать не с одним человеком – лица, ответственные за проект, меняются. 1 6 61 Взгляды на итоги проекта, например, у ИТ-директора и директора по финансам — совершенно разные. Часто возникают ситуации, при которых исполнители, то есть ИТ-специалисты гораздо больше удовлетворены проектом, чем его заказчики, потому что исполнителям видна конкретная работа (система внедрена и действует), но заказчик при этом может не получить желаемого. Другой вопрос, что желаемое, возможно, недостижимо. Такое развитие событий не исключено — мы говорили об этом в разделе про постановку целей управленческого учета. Нередко клиент хочет систему, хотя на самом деле ему нужно просто навести порядок в финансовом департаменте. Система этому не поспособствует и не мешает. У заказчика необходимо спросить о целях проекта и насколько они были достигнуты. Здесь следует избегать ловушки: согласно статистике цели по мере внедрения меняются. Поэтому уточните, не корректировались ли цели. Расспросите референтного клиента, как они выбирали систему, поделитесь с ними своими предположениями и планами дальнейших действий. Можно взять перечень разделов, которые есть в этой главе, и задать вопрос по каждому из них: • Как удалось выбрать систему? • По каким критериям выбрали для себя поставщика? • Что являлось «пилотным» проектом? • Были ли проблемы на стадии тестирования? • Как шла подготовка к проекту? • Как формировалась рабочая группа проекта? • Как люди мотивировались? • Как они составляли устав, оценивали результаты и эффективность? Короче говоря, вы можете задать руководителям референтной компании вопросы по каждому разделу данной книги: «А делали ли вы это? А как вы это делали?» Команда Ваши вопросы во время референтного визита могут конкретизироваться вплоть до фамилий конкретных 2 6 62 консультантов. Они пригодятся во время обсуждения с консультантом команды внедрения. Не секрет — чтобы оценить, кто и насколько качественно будет делать для вас работу, необходимо как минимум запросить резюме предполагаемых кандидатов внедрения, а как максимум — встретиться с каждым и лично побеседовать. Кроме общепринятых элементов — образование, опыт работы, знания в профессиональной области, оцененные в виде не столько курсов, сколько сертификатов — полезно оценить научную деятельность, то есть публикации и околопрофессиональные интересы. Что имеется в виду? Консультант не обязан быть бухгалтером или финансовым менеджером, но он должен владеть соответствующими науками. Если у человека, который предположительно будет внедрять у вас блок «Финансы», есть сертификация СРА или США в Management Accounting, значит, он — действительно ценный специалист. В практике нашей компании резюме включает поле «Публикации». Это стимулирует консультантов писать статьи и размещать их в научно-популярных изданиях. Пустота в этой графе заставляет задуматься о достаточности профессионализма. Конечно, чем больше официальных сертификатов есть на счету у того или иного консультанта, тем выше оплата его труда. Но жизнь подсказывает, что лучше переплатить за предсказуемое качество, чем за непредсказуемые ошибки. Глава 1.5. Как подготовиться к внедрению системы Проверка боем Все, о чем мы говорили в области постановки управленческого учета, и является подготовкой к внедрению будущей системы. Потому что к данному моменту вы создаете центр компетенции, который владеет ситуацией; знает, какие цели стоят перед внедрением управленческого учета. Людей в группу нужно подбирать, в том числе исходя из их склонности к компьютеризации и автоматизации собственного труда. Необязательно, чтобы они были ИТ-специалистами, но жилка постановщика задач необходима. 3 6 63 Если у вас на предприятии никогда не реализовывался проект по внедрению какой бы то ни было компьютерной системы (именно системы, заставляющей изменить стиль и подходы к работе, меняющей вашу организацию), рекомендуется начать с небольшого проекта — попробовать, что это такое. Любой проект внедрения информационной системы для управленческого учета может предваряться другими проектами, например, по созданию единых справочников и справочнонормативной документации, автоматизации стратегического управления и т.п. То есть приветствуется выделение части из глобального проекта управленческого учета, если эта часть станет для вас полезной тренировкой. СМК Существует и такой тип проекта подготовки ко внедрению системы. Если ваше предприятие занимается производством и целью внедрения управленческого учета является в том числе повышение качества обслуживания клиентов, вы можете рассмотреть вариант внедрения системы менеджмента качества (СМК). Это очень хороший подготовительный маневр, который приносит ощутимые результаты. В итоге вы должны получить от независимых экспертов сертификат по необходимому стандарту — серии ISO, ГОСТы, отраслевые стандарты. Таблица 1.3. Этапы создания СМК Анализ и разработка политики качества, определение ответственности руководства, области сертификации Обучение руководителей и специалистов на специализированных курсах Разработка детального плана, руководства по качеству. Определение совокупности производственных и управленческих процессов, в том числе тех, которые можно автоматизировать в дальнейшем при реализации ERPсистем Обучение персонала компании Аудит предварительный Разработка шаблонов регламентных документов, консультации по сбору, обработке и анализу статистики 4 6 64 Консультации по устранению выявленных на предварительном аудите несоответствий, анализ статистики по несоответствиям Внешний аудит аккредитованной независимой компанией Ознакомьтесь со списком этапов, которые обязательно должен включать проект внедрения СМК (табл. 1.3), и вы поймете, что это достаточно серьезный проект, сопоставимый по времени с внедрением, по крайней мере, части комплексной информационной системы. Смысл провести его до внедрения системы управленческого учета есть: он порождает документы, которые впоследствии помогут. Вообще, чем больше документов, регламентирующих и описывающих бизнес-процессы, тем легче и быстрее пройдет внедрение системы УУ. Не придется тратить время на обследование — описывая свою деятельность, вы расставляете приоритеты. В качестве доказательств можно привести массу случаев, когда руководство просит подчиненных составить список их должностных обязанностей. Очень многих это задание повергает если не в шок, то в ступор. Потому что гораздо проще заниматься рутиной, чем ее описывать. Если рутина не описана, она, вроде, таковой и не является. А когда все описано, остается ужаснуться: «Господи! Неужели я всем этим занимаюсь каждый рабочий день?» Данный эксперимент позволит вам добиться конкретного результата и понять, что такое не входящий в вашу основную деятельность проект. Почему такие проекты сложнее? Потому что они действительно не входят в вашу профессиональную деятельность. Все, о чем мы рассказываем в этой книге, — проекты по СМК, другие аналогичные проекты — характеризуют людей, которые ими занимаются. Они посвящают этому практически все свободное от работы время. Конечно, вы можете выделить руководителя проекта на full time (это приветствуется и станет гарантией завершения проекта в намеченные сроки и в нужном объеме). Но зачастую исполнители, эксперты, члены центра компетенции — все занимаются проектами не full time, и 5 6 65 помимо задач проекта должны выполнять еще основные трудовые обязанности. Поэтому любой проект, осуществленный в рамках вашей организации и являющийся не основной деятельностью, очень полезен для осознания, сможете ли вы выделять дополнительное время своих людей. Администратор Вам необходимо определить, кто будет администрировать будущую систему и какие требования предъявлять к ее администратору На период внедрения или, по крайней мере, на большинстве этапов консультанты будут находиться в вашем офисе. Значит, для них нужно предусмотреть рабочие места, средства коммуникации, определиться с допуском на территорию предприятия, системой информационной безопасности. Потому что если вы дорожите своими данными, то все настройки и моделирование нужно производить в рамках вашего офиса. Если вы не собираетесь давать консультантам удаленный доступ к своей системе и данным, это тоже нужно предусмотреть и заранее обсудить — не все интеграторы работают в таком режиме. Мотивационная программа Очень важно еще до начала операций по внедрению бизнес-приложения проработать у себя систему мотивации персонала — тех, кто задействован в проекте. Почему это необходимо? В первую очередь потому, что люди будут больше загружены, чем ранее. И речь идет не только о материальной мотивации. Как всегда, нужно не забывать о мотивации профессиональной, апеллировать к амбициям, дать понять сотрудникам, что проект реализуется для перехода компании на качественно новый уровень, и его участники смогут добиться нового статуса, а возможно, и новых постов. Ответственные за выполнение проекта должны рассматривать для себя участие в нем как честь, возможность развиваться. Это, пожалуй, самый важный стимулирующий критерий. Кроме того, многие из задействованных в проекте специалистов должны получить и материальное поощрение. 6 66 Существует масса критериев, по которым распределяются наградные суммы. Но, пожалуй, самым важным является нацеленность на достижение результата в оговоренные сроки и в нужном объеме. Если к реализации проекта привлекаются консультанты, вы должны быть уверены, что принцип награждения ваших сотрудников максимально соответствует принципу награждения консультантов. Например, вы заключили договор с консультантом на основе time-sheet. Он будет приходить в компанию и должен быть заинтересован в том, чтобы провести у вас как можно больше времени и получить за это максимальный бонус. Если с вашей стороны с этим консультантом будет работать человек, ответственный за конечный результат в ограниченные сроки, возникнет конфликт интересов. Несколько слов по поводу оплаты по time-sheet. Считается, что это порочная практика, но бывают ситуации, в которых подобная плата оправданна. В нашем случае – на стадии промышленной эксплуатации. С этого момента вы начинаете платить консультантам по timesheet, чтобы иметь стимул как можно быстрее самим освоить систему и научиться с ней работать. Речь идет не об ошибках в системе, а об извечном страхе человека, который впервые сел на велосипед, уже сам едет, остаться без «учителя». Приведение систем стимулирования вашего персонала и персонала интегратора к единым принципам поможет создать общую команду внедрения. Часто складываются ситуации, когда консультанты работают «до последнего акта»: если нет финального документа, результаты всего проекта можно оспорить. В то время как сотрудники заказчика, выделенные на проект, получают премию за выполнение проекта, скажем, с момента запуска системы в эксплуатацию. Многие, кстати, разбивают понятие физической завершенности работы и бумажные дела. Иным кажется, что система заработала, все хорошо, акт можно подписывать, но проходит день, два, три, пять, но акт не подписывается. Возникают какие-то вопросы — 7 6 67 мол, система работает не так, как хотелось. Консультант начинает опровергать домыслы. То ли вы неправильно составили цели, то ли консультант нечист на руку. Дело в том, что подписание финального акта — признание работоспособности системы и того факта, что проект завершен. Поэтому в опытных консалтинговых организациях бонус консультантов привязан именно к данному моменту. По этой причине положение о мотивации сотрудников, задействованных на проекте, обязательно должно быть нацелено на конечную цель — подписание акта. Ошибки мотивации персонала Мы приводим пример проекта, который формально состоит из двух этапов. Это длительный по времени процесс, и у вас может возникнуть потребность разбить предполагаемую премию на две части: одну выплатить по окончании первого этапа, вторую — по завершении второго. В проектах внедрения комплексных систем, как и в любых других, действует принцип роста важности каждого следующего этапа. Поэтому будьте внимательны и добейтесь, чтобы основная сумма выдавалась после подписания финального акта. Иначе, взяв половину бонуса, люди не будут стараться должным образом выполнить оставшуюся часть проекта. Промежуточные выплаты, безусловно, нужны, но они должны быть мизерными по отношению к окончательной сумме (все вместе не должны превышать 40% от предполагаемого бонуса). Обучение пользователей Многие компании выделяют обучение персонала в отдельный проект или вид работ. Это правильный подход. Обучение, если речь идет о десятках, а то и сотне специалистов, является сложным с координационной точки зрения процессом. Вдобавок эти люди находятся в разных офисах, а офисы часто — в разных городах и т.д. Рекомендуется обратить внимание на дистанционное обучение. Есть фирмы, которые специализируются на таких курсах. Причем делают даже то, что не входит в типовую программу. Их можно привлечь, чтобы консультант научил все ваши филиалы работе в системе. 8 6 68 Дистанционное обучение подразумевает разные формы. Например, веб-семинар. Его главный минус — затраты на международную связь. Даже если пытаться минимизировать эти затраты с помощью IP-телефонии или Skype-технологий, далеко не везде не все каналы обеспечивают приемлемую связь. Есть и другой недостаток — отсутствие контакта с преподавателем. Здесь я хочу уберечь вас от иллюзий: немногие консультанты выделяют на обучение ценных, опытных специалистов, которые могут ответить на широкий круг вопросов. Это естественный ход вещей. Успешная консалтинговая компания продает новые проекты, хотя не всегда успевает за темпом их появления. Отсюда — дефицит квалифицированных работников. Держать опытного консультанта лишь для обучения невыгодно. Если проект внедрения продан, речь идет о большом долгосрочном контракте. Все фазы, вопросы взаимодействия и вовлечения других специалистов в нем предопределены. Обучение же, если оно продается как отдельный продукт, менее предсказуемо, поскольку сам проект меньше по объему. Гораздо легче предсказать, где будет занят сотрудник на проекте внедрения, поскольку это продлится минимум шесть месяцев. А что он будет делать на проекте обучения в одну неделю? Спланировать такую неделю в течение полугода очень непросто. Именно поэтому на обучение вы можете и не получить высококачественный учебный материал. Под качеством мы понимаем, что нам дадут нечто большее, нежели «сухой» учебный материал по теме. Обучение конечных пользователей должно проводиться по конечным инструкциям. В них прописываются правила работы с конкретными рабочими местами. Поскольку все они персонифицированы, трудно объединить множество специалистов в группы. Вводное обучение рассказывает будущим пользователям, как работать с системой, ее устройство и т.д., то есть дает базовые знания. Согласно современным тенденциям развития бизнесприложений, все идет к тому, что эти знания для широкого круга лиц скоро перестанут быть необходимыми. Дружелюбный 9 6 69 интерфейс предполагает, что пользование системой ничем не отличается от пользования теми продуктами, к которым мы привыкли, — Windows, Linux, Office. Базовые сведения о системе, более или менее глубокие, нужны лишь членам координационного комитета, точнее — членам рабочей группы. Они должны понимать архитектуру системы, чтобы осознанно принимать техническое задание, участие в разработке, настройке и запуске системы. Что касается ролевых обучений, то порой оно сводится к работе в кружках. Мы берем конкретную роль — закупщик материалов. Сколько человек может быть задействовано в этой роли? Даже в большой организации максимум — пятеро. Чтобы рассказать этим людям, как работать с системой любой категории сложности, хватит и одного рабочего дня. Такое занятие вполне может провести специалист, который в рабочей группе занимался настройкой закупок. Е. Плаксенков: «Нужно принять как факт, что у людей существует определенная скорость принятия нового. Например, по ходу развития компания решилась выставить какие-то небывалые требования к финансистам. Начали увольняться те, кто не хочет их выполнять. Сразу стали набирать других, лояльных к системе. Заявив на входе о принятии условий, такие сотрудники не могут не поддержать новую систему. Им говорят: «Мы внедряем такую-то систему. Критерий качества вашей работы — отношение к ней и скорость внедрения». Так мгновенно задается иная динамика, с которой внедрение проходит гораздо быстрее. Но для этого надо принять решение, что ты отказываешься от прежнего персонала в пользу новых людей. Если возможность есть — флаг в руки. Бизнес — не просто работа, это жизнь. Гораздо сложнее сделать так, чтобы люди изменились, заставили себя научиться новому. Для них это испытание: спокойно работал, а тут еще учиться надо. Но ведь новое образование — возможность развиваться, работать на качественно ином уровне. Для компании это важно. Мне, 7 70 например, менять людей как перчатки неинтересно. Да, можно себе позволить создавать подобные условия. Но намного интереснее, когда происходит эволюция тебя самого и среди людей, которые тебя окружают. Мне кажется, что это более экологичное состояние бизнеса». А вот пример диаметрально противоположного подхода от сети аптек «36,6»: Б. Рябов: «Мы использовали особый вид мотивации при запуске системы — безальтернативная. С самого начала было сказано: «Что бы ни произошло, с такого-то числа вы работаете в новой системе». Все мосты сожжены. Это — эффективная мотивация. Мотивация обратного характера в случае внедрения системы — большая редкость, поскольку она не всегда возможна. Проблема в том, что возникают моменты, когда нельзя повернуть назад. Люди начинают работать сутками не потому, что им заплатят, а потому, что если они сейчас этого не сделают, потом не смогут работать. Смесь страха, ответственности и совести. Самое главное — донести идею безальтернативности; от вашего бездействия проект не остановится, но из-за проблем проекта ваша деятельность может серьезно осложниться». Глава 1.6. Методология внедрения Подход к созданию АСУП. Описание методики Внедрение и автоматизация управленческого учета представляет собой процесс создания автоматизированной системы управления предприятием (АСУП). Дело в том, что компьютерное бизнес-приложение само по себе еще не является системой управления. Система управления предприятием — это организационно-технический комплекс, техническая часть которого, с точки зрения трудозатрат, не является самой емкой. Построение АСУП — работа не столько с приложениями, сколько с людьми. Иными словами: 1 7 71 Внедренный управленческий учет = = Построенная и эксплуатируемая АСУП АСУП = Настроенное бизнес-приложение + «Настроенные» люди Связь между программным средством и системой Система является комбинацией технических средств, компьютеров, программных средств, материалов, персонала и возможностей, как показано на рис. 1.2. Все это фактически образует работоспособную систему. В исходной системе существуют реальные процессы. Программные средства обеспечивают выполнение некоторых функций данных процессов на компьютерах. Они могут быть постоянно (резидентно) размещены в компьютерах, встроены как программы, реализованные техническими средствами, или интегрированы в объект технических средств. В любом случае заказ, поставку, разработку, эксплуатацию или сопровождение программных средств необходимо координировать и гармонизировать с аналогичными процессами для исходной системы. Рис. 1.2. Связь между программным средством и системой 2 7 72 Вашему вниманию предлагается концептуальное описание методических подходов к созданию АСУП с применением типовых проектных решений (ТПР, в том числе отраслевые решения). ТПР — бизнес-приложение или комплекс приложений, настроенных для решения определенного перечня бизнес-задач. Эти задачи носят тиражируемый характер и могут быть востребованы многими компаниями. Например, отраслевое решение — типичный ТПР. Он представляет собой готовое решение (проектные и эксплуатационные документы, модели, алгоритмы, программный код, схемы данных, классификаторы), которое может значительно сократить затраты времени и ресурсов на настройку и адаптацию бизнес-приложения. Решив использовать ТПР, вы должны дать принципиальное согласие на приведение процессов своей фирмы в соответствие со структурой, программной логикой, форматами данных и классификаторами, используемыми в ТПР. Обоснованное решение о возможности использования ТПР может быть принято лишь по результатам предпроектного обследования вашего предприятия с привлечением консультантов и других специалистов, обладающих необходимыми знаниями предметной области, функциональных возможностей и ограничений ТПР. Данные методические подходы основаны на проектном опыте консалтинговых компаний, внедряющих бизнесприложения, российских и международных стандартов и методик в области проектирования. При описании учитывались следующие допущения: • В ходе проекта максимально задействуются специалисты заказчика; особенно в задачах, связанных с эксплуатацией и сопровождением системы. • Методики не покрывают вопросы проектирования инфраструктурных ресурсов: аппаратного обеспечения, телекоммуникаций и т. п. Классификация функций АСУП Использование стандартных классификаторов функций АСУП и автоматизируемых бизнес-процессов позволяет 3 7 73 развивать систему в рамках нескольких смежных проектов и накапливать опыт реализации функций. Наименование функции АСУП должно включать управляющее действие («управление», «планирование», «прогнозирование», «учет», «контроль», «анализ», «координация», «регулирование») и объект управления (бизнес-процесс или функция). Например, правильное название функции «Управление закупками», а не «Закупки». Классификатор реализуемых в АСУП функций должен быть составлен таким образом, чтобы вам и вашим консультантам было понятно не только, что именно автоматизируется, но и что делать не нужно. Использование стандартизованной функциональной структуры АСУП позволяет избежать проблем, связанных с несоответствием проектных ожиданий заказчика. Выбранный классификатор должен иметь иерархическую структуру. В частности, следует однозначно определить, что в подсистему «Управление финансовыми ресурсами» входит (или не входит): • ведение бухгалтерского учета (ведение главной книги, кассовых операций, банковских счетов; формирование регламентированных отчетных документов: бухгалтерский баланс, отчет о прибылях и убытках и т. д.; подготовка счетов, платежных документов, расчет заработной платы); • ведение налогового учета; • расчет себестоимости продукции, остатков незавершенного производства; • мониторинг основных производственных процессов и производственных показателей; • кредитный менеджмент; • управление основными средствами, нематериальными активами. Стадии ЖЦ АСУП Состав стадий жизненного цикла (ЖЦ) АСУП Жизненный цикл создания АСУП состоит из стадий, перечисленных в табл. 1.4. 4 7 74 Таблица 1.4. Стадии жизненного цикла АСУП № 1. 2. 3. 4. 5. 6. 7. Стадия Предпроектное обследование Определение требований Системное проектирование Техническое проектирование Реализация АС Ввод в действие Эксплуатация АС ID А В С D Е F Стадии 1 и 7 жизненного цикла проектирования системы здесь подробно не описываются. Потому что состав работ по первой стадии всегда индивидуален. Их цель — определить с максимальной точностью рамки проекта. А стадия 7 «Эксплуатация АС» фактически относится к ЖЦ системы как таковой, и указана здесь для полноты картины, так как достоверным критерием внедрения является ее реальная эксплуатация. Завершение каждой стадии фиксируется актом сдачиприемки работ. Проект по созданию и развитию АСУП в зависимости от состояния системы и выполненных ранее проектов может включать разные стадии. При использовании ТПР можно исключать из проекта задачи, работы и целые стадии, если соответствующие решения уже есть в готовом виде в ТПР. 5 7 75 Рис. 1.3. Жизненный цикл проекта по созданию АСУП Если после исключения задач оказывается, что состав работ какой-либо стадии минимизирован до предела, ее выделение в проекте может стать бессмысленным. В таком случае стадии следует объединять. Возможно объединение стадий: А + В, С + D. Другие стадии объединять нельзя (табл. 1.5). Таблица 1.5. Наименование объединенных стадий № 1. 2. Объединяемые стадии А+В C+D Наименование объединенной стадии Определение требований Реализация АСУП 6 7 76 Стадия А. Определение требований Цели и задачи стадии В результате выполнения работ стадии должны быть достигнуты следующие цели: • согласованность связанных целей бизнеса и автоматизации; • заинтересованность высших руководителей в проекте; • определенность недостатков существующих процессов и информационной системы; • корректное понимание задач, которые требуется решить в проекте для достижения бизнес-целей; • вывод о возможности и целесообразности решения бизнесзадач выбранными средствами; • снижение рисков проекта путем более детального (по сравнению с договором) определения логических рамок автоматизируемых бизнес-процессов; • определенность источников эффективности проекта; • сопоставление существующих процессов с решениями, заложенными в программных приложениях; • согласованная оптимизированная модель бизнес-процессов, учитывающая принятую программную платформу и доступные способы автоматизации функций; • согласованное понимание рамок проекта и детальный (по следующей стадии) план проектирования (план проектирования итерационно детализируется на каждой стадии). Таблица 1.6. Состав работ стадии «Определение требований» по этапам Этап Работы А 1. Планирование и организация работ проекта РМ1. Планирование проекта и стадий (А) ОD4. Организация работ на объекте ID2. Подготовка среды проекта (А) ОD2. Подготовка проектной команды А 2. Сбор и анализ данных 7 77 BR1. Анализ архитектуры бизнес-процессов BR2. Определение бизнес-требований ID1. Проектирование информационной инфраструктуры (А) A 3. Формирование концепций проекта ОD1. Организационное проектирование (А) DО1. Регламентирование документации ID1. Проектирование информационной инфраструктуры (А) А 4. Постановка задачи BR3. Отражение бизнес-требований (А) DО2. Разработка проектной документации (А) А 5. Завершение определения требований РМ3. Завершение стадии и проекта (А) Рекомендации по выполнению работ Этап А 1. Планирование и организация работ проекта Сразу после подписания договора руководитель вашей организации должен издать приказ по предприятию о назначении специалистов в группу внедрения, куда должны войти как специалисты разработчика (консультанта), так и ответственные исполнители с вашей стороны (см. приложение 3 «Устав проекта»). В число ответственных исполнителей могут войти члены центра компетенции, образованного в ходе проектирования управленческого учета. Если проект реализуется с помощью внешних консультантов, отвечающих за конечный результат, руководителем совместной группы внедрения проекта должен быть назначен менеджер проекта со стороны исполнителя. Выходные документы стадии «Определение требований»: • планирование и организация работ проекта (требования заказчика); • сбор и анализ данных (описание существующей информационной инфраструктуры); • формирование концепции проекта; • постановка задачи (отчет об обследовании объекта); • завершение определения требований. 8 7 78 Далее проводится встреча рабочей группы проекта (или ее руководителей) с высшим руководством вашей компании для выявления и согласования: • уточненных логических рамок и целей проекта создания АС; • используемого подхода; • основных проблем или областей возможной оптимизации бизнеса; • состава ответственных представителей по вопросам проекта; • порядка работы с руководителями подразделений. Рис. 1.4. Этапы работ стадии «Определение требований» и Менеджер проекта согласовывает состав группы внедрения план встреч со специалистами клиента, организует 9 7 79 предоставление информации по стратегии, существующим бизнес-процессам и информационной системе. Для работы группы внедрения (рабочей группы) нужно создать необходимую производственную среду: помещения, удовлетворяющие установленным требованиям; коммуникации; при необходимости — транспорт и питание. Среда должна обеспечивать возможность интервьюирования, сбора и документирования данных обследования, обучения персонала группы внедрения, презентации результатов. Этап А 2. Сбор и анализ данных На основе данных «Предпроектного обследования» выполняется анализ архитектуры бизнес-процессов, в ходе которого необходимо разработать верхнеуровневое описание существующих процессов (ВР.070 «Описание процессов»). Должна быть документирована информация по составу автоматизируемых функций БП, составу необходимых АРМ и планируемых изменениях в БП. Также собирается информация о необходимых рабочих местах пользователей и инфраструктуре объекта. Документ может быть оформлен как часть отчета об обследовании. Если вы проектировали оперативный учет, основным источником сведений для данного этапа является перечень документов, которые вы разработали: • бизнес-функции; • бизнес-процессы; • перечень объектов и субъектов оперативного учета. На основе описания процессов проводится обследование предприятия с целью определить комплексные бизнестребования. В ходе обследования рекомендуется такая последовательность работ: • (при отсутствии постановки ОУ) на основании списка обследуемых бизнес-процессов проводятся интервью с ответственными за процессы (владельцами процессов) на предприятии; • (при отсутствии постановки ОУ) анализируются существующие на предприятии формы документов; 8 80 формируется «Ведомость первичных документов» в виде отдельного приложения к отчету об обследовании; первичные документы собираются по структурным подразделениям (входящие/исходящие); • выясняются пожелания пользователей будущей системы (начиная с руководства) относительно модификации старых отчетов и создания новых; • собирается формализованная информация: органиграммы, схемы площадок, схемы корпоративной сети, функциональные и структурно-технические схемы существующей ИС, модели процессов и т. п.; • проводится обследование существующей ИС на предмет выяснения недостатков и предлагаются возможные пути их устранения; не требуется глубокое изучение информационной инфраструктуры; • на основании интервью проводится детализация целей бизнес-процессов и ИС до уровня измеримости; выясняются критерии их достижения; дерево целей удобно представить в виде таблицы; • на основе стандартной классификации и полученных данных о функциональной структуре описываются функции бизнес-процессов 2-3 уровня. 1. Информационный анализ Необходимо в минимальном виде проводить информационный анализ выходных информационных потоков (например, отчетности), входных информационных потоков (например, первичных документов) с целью определения: • достаточности входных информационных потоков для получения выходных; • непротиворечивости, дублирования информационных потоков; • унификации информационных потоков и форм документов; • соответствия информационных потоков логическим рамкам проекта (структура информации, состав реквизитов документов). 1 8 81 2.Построение дерева целей Сначала для существующих бизнес-процессов определяются цели верхнего уровня. Необходимо помнить, что цели бизнеса и цели построения АСУП — разные по своей природе цели. В идеале, за основу целеполагания проекта в вашей организации берется существующая система целей и показателей (ССП и т.п.). Затем определяются цели будущей автоматизированной системы и проводится их квантификация (детализация с выполнением требований полноты, корректности, независимости и непротиворечивости) до уровня, когда: • критерии достижения цели становятся измеримыми; • цели системы связаны и согласованы с целями бизнеспроцессов. При построении дерева целей необходимо, насколько это возможно, придерживаться правила независимости целей одного уровня друг от друга. Цели должны формулироваться просто, с низким уровнем иерархии. Их количество должно быть сведено к минимуму. Дерево целей следует согласовать с руководством заказчика. Доказательство необходимости проектирования системы строится на соотнесении целей создаваемой системы и целей бизнеса, а также на источниках экономической эффективности. Если систему предполагается создавать по очередям, цели ее создания должны быть двух качественных уровней. Общие цели всех очередей системы следует формулировать в общем концептуальном виде. Они предназначены для определения общего направления развития и максимально соответствуют целям бизнес-процессов. Такие цели могут не иметь четкого горизонта планирования, контекстно измеримых критериев и целевых значений. Общая методика целеполагания изложена в разделе 1 «Управленческое планирование». 3.Построение моделей На основании проанализированных данных о существующей системе строится модель бизнес-процессов 2 8 82 «как есть». Ее необходимо детализировать до уровня, на котором будет понятно, какие бизнес-функции можно автоматизировать. Если для успешной автоматизации потребуется изменение (оптимизация) существующих бизнес-процессов, строится модель «как должно быть» или руководству заказчика представляются рекомендации по изменению (для обсуждения). Форма представления моделей может быть графической или в виде текстового описания. По результатам работ этапа формируются рабочие документы — «Бизнес-требования» и «Общее описание существующей информационной инфраструктуры». Затем оба включаются в виде приложений или разделов в «Отчет об обследовании объекта». Этап A 3. Формирование концепций проекта Назначение данного этапа — разработка и согласование с заказчиком проектных стратегий в области организационного проектирования, создания необходимой инфраструктуры и документирования проекта. В стратегиях отражаются основные принципы, ограничения, элементы политики, которые будут выполняться в проекте. Разрабатывается «Глоссарий» терминов предметной области, функциональных и информационных терминов и объектов для их однозначного толкования специалистами обеих сторон. Стратегии проекта также включаются в отчет об обследовании и впредь являются руководством для принятия проектных решений. Этап А 4. Постановка задачи Анализируются расхождения между бизнес-требованиями и ситуацией «как есть». Основные критерии анализа — минимизация отклонений от стандарта, «прозрачность» процессов и удобство управления ими. Принимаются решения бизнес-уровня о путях преодоления выявленных расхождений и целесообразности автоматизации функций бизнес-процессов для разрешения противоречий. Оформляется и согласовывается «Отчет об обследовании предприятия». 3 8 83 Утверждение «Отчета об обследовании объекта» заказчиком обычно не требуется, так как этот документ является информационным (не устанавливает требований). Рекомендуется после представления отчета провести презентацию итогов работ стадии для руководства вашего предприятия. Отличия при использовании ТПР Использование на стадии «Определение требований» готовых решений в виде ТПР подразумевает наличие, прежде всего, типовой бизнес-модели, на использование которой рассчитано внедрение заложенных в ТПР системных и программных решений. Указанная бизнес-модель должна включать функциональную, информационную, процессную и организационную модели, описание бизнес-процессов и ключевых алгоритмов, словари и классификаторы предметной области, основные структурные требования (многофилиальность, мультивалютность и т.п.). Отказ от типовой бизнесмодели иногда приводит к невозможности использования или резкому снижению эффективности всего ТПР. По этой причине принципиально важно выполнить ряд работ, позволяющих выявить и зафиксировать степень расхождений между типовой и существующей бизнес-моделями, возможности и способ приведения существующих процессов к предлагаемой модели. Обследование объекта сводится в таких условиях к получению информации, которая позволяет сравнить нынешние процессы с эталоном по контрольным точкам: соответствует или нет? По результатам обследования должны быть сформулированы рекомендации по приведению бизнес-процессов в гармонию. Обязательным условием такого сценария является полученное при заключении договора согласие и готовность заказчика на изменение процессов согласно требованиям ТПР. Параллельно выясняется состав и содержание необходимых доработок и адаптации имеющихся программных решений. Полученная информация и принятые для использования ТПР решения должны быть систематизированы, четко сформулированы в стандартных документах и согласованы с заказчиком до дальнейшего использования в проекте. 4 8 84 • • • • • • • Стадия В. Системное проектирование Цели стадии Основными целями стадии являются: определение организационных, функциональных, информационных и эксплуатационных требований к системе; проработка автоматизируемых информационных процессов до уровня элементов инфраструктуры; отражение бизнес-требований через возможности программных приложений; демонстрация осуществимости проектируемых бизнеспроцессов для вашего предприятия; определение требований к персоналу, регламенту и информационной инфраструктуре; предложение способа перехода на новую систему; определение требований по интеграции с другими системами и приложениями. Таблица 1.7. Состав работ стадии «Системное проектирование» по этапам Этап Работы В 1. Планирование системного проектирования РМ1. Планирование проекта и стадий (В) 0D4. Организация работ на объекте ID2. Подготовка среды проекта (В) В 2. Анализ и оптимизация системных требований BR3. Отражение бизнес-требований (В) SE1. Формирование системных требований SE2. Планирование безопасности ST1. Регламентирование тестирования AD1. Доработка или адаптация программ (В) AD2. Конвертирование данных (В) В З. Планирование работ по созданию АС 0D1. Организационное проектирование 0D3. Подготовка персонала (В) В 4. Разработка технического задания D02. Разработка проектной документации (В) В 5. Завершение системного проектирования РМЗ. Завершение стадии и проекта (В) 5 8 85 Рис. 1.5. Этапы работ стадии «Системное проектирование» Выходные документы • планирование работ по созданию АС — план подготовки объекта; • разработка технического задания — техническое задание на создание АС; • завершение системного проектирования — акт приемкисдачи работ. Рекомендации по выполнению работ Этап В 1. Планирование системного проектирования При организации работы группы внедрения необходимо создать среду для возможного прототипирования (см. «Прототипирование» далее) и использования прототипа для установления требований заказчика (отражения бизнестребований). Этап В 2. Анализ и оптимизация системных требований 6 8 86 На основе «Отчета об обследовании объекта», анкет и результатов интервью производится анализ требований заказчика к будущей системе. Он заключается в их систематизации, унификации и стандартизации, уточнении с клиентом, обосновании, расстановке приоритетов в соответствии с определенными в «Отчете об обследовании объекта» целями автоматизируемых бизнес-процессов и создаваемой системы. Прототипирование Используется для уточнения требований к системе, демонстрации ее возможностей и способа отражения бизнестребований. Прототип приложения может строиться на основе стандартной версии программ из состава программной платформы или с использованием прототипа из состава ТПР. Он служит действующей имитационной моделью системы. Полезно использовать прототип для демонстрации и отладки процедур взаимодействия со смежными системами (фронт-офис, клиент-банк, АСУТП, САПР и т. п.) путем запуска прототипа на опытном стенде с использованием средств интеграции и сбора данных: кассовых аппаратов; систем электронного документооборота, идентификации и контроля доступа, промышленной автоматики и т. п. Рекомендуется начать использовать прототип как можно раньше. Это позволит более точно определить требования ключевых пользователей к будущей системе и ее интерфейсам. Наличие прототипа не освобождает от документирования требований и не заменяет формальных спецификаций, но может их дополнять. Основные проектные задачи, решаемые с помощью прототипирования: • согласование модели ТО-ВЕ как иллюстрации способа отражения требований; • проверка возможности реализации бизнес-требований; • проверка и отладка способов интеграции с внешними системами; 7 8 87 • оценка трудоемкости реализации. В ряде случаев является целесообразной тестовая загрузка отдельных массивов данных вашей компании в прототип. Это позволяет подготовить верификацию начальных данных, решить вопрос о возможности их загрузки на ранних стадиях (на подготовку часто уходит значительное время). Планирование доработок На основании сопоставления системных требований и имеющегося прототипа или ТПР разрабатывается список необходимых доработок бизнес-приложений. При этом надо учитывать принятую проектную стратегию по доработкам: сколько и какой сложности доработки могут быть в данном проекте, какие из них следует перенести на сопровождение, что придется выполнить заказчику после приемки системы в эксплуатацию, какие операции невозможны в принципе и т. д. Для каждой доработки нужно оценить требуемые ресурсы и сроки ее выполнения. Рекомендуется вести «План доработок», начиная со стадии «Системное проектирование» и до момента их полного выполнения на стадии «Реализация АС». Планирование конвертирования Для запуска бизнес-приложения в эксплуатацию необходимо ввести в него актуальные начальные данные: нормативно-справочную информацию, начальные остатки и документы. Часть этих сведений можно получить из наследуемых систем, другие вводятся вручную. Независимо от способа ввода требуется обеспечить все аспекты безопасности информации: конфиденциальность, целостность и доступность. Ключевым фактором является целостность, которая во многом определяется актуальностью данных на момент запуска. Нужно планировать следующие основные задачи конвертирования данных: 1. Назначить ответственных за конвертирование. 2. Определить требования к конвертированию данных. 8 88 3. Разработать схемы и алгоритмы конвертирования. 4. Разработать процедуры ручного конвертирования и ввода данных. 5. Разработать и протестировать средства конвертирования. 6. Проверить корректность и подготовить начальные данные к конвертированию. 7. Планировать ресурсы, время, последовательность конвертирования (план-график). 8. Организовать и провести конвертирование в соответствии с планами проекта. 9. Выполнить проверку полученных данных. Результаты планирования аналогично конвертированию данных лучше отражать в «Плане конвертирования». Его также удобно итерационно вести на протяжении проекта. Работы по конвертированию должны быть синхронизированы с работами по доработке приложений. Этап В З. Планирование работ по созданию АС Подготовка ключевых пользователей В связи с тем, что подготовка персонала — длительный процесс, предварительное выделение ключевых пользователей и их обучение по общим вопросам (например, курсы по использованию программной платформы в учебном центре) лучше проводить как можно раньше. Чем раньше ключевые пользователи будут обучены основам работы с программой, тем скорее их можно будет полноценно использовать для формирования и согласования требований к системе и обучения конечных пользователей. Кроме того, обучение ключевых пользователей работе с программной платформой позволяет получить активных сторонников проекта в организации заказчика, что положительно влияет на ход проекта в целом. Подготовка объекта к вводу системы в действие Для успешного запуска АСУП недостаточно просто выполнить работы по ее созданию. Надо — до начала стадии «Ввод в действие» — провести техническую и организационную 9 8 89 подготовку самого объекта. Эти работы должны планироваться на «Системном проектировании». Техническая подготовка объекта включает: 1. Разработку заданий на проектирование в смежных областях. 2. Разработку технического регламента. 3. Подготовку обслуживающего персонала. 4. Закупку комплектующих. 5. Разработку и реализацию инфраструктуры нижних уровней. 6. Запуск процесса эксплуатации и управления информационными ресурсами. Организационная подготовка объекта включает: • Создание структурных подразделении и изменение существующей оргструктуры. • Включение новых функций в обязанности служб. • Создание новых должностных позиций. • Инструктаж персонала организации (не персонала проекта внедрения АСУП), чья деятельность может измениться после запуска системы. • Выделение персонала для работы в группе внедрения. • Оповещение персонала организации об изменениях технологии и регламента работ. • Мотивацию персонала и т. д. Этап В 4. Разработка технического задания Типовое содержание ТЗ приведено на прилагаемом к данному руководству CD. Техническое задание является главным документом, на базе которого создается система. Готовое техническое задание утверждается заказчиком и служит формальным основанием для подписания акта приемки-сдачи работ по стадии «Системное проектирование». Стадия С. Техническое проектирование Цели стадии Основными целями стадии являются: • проект доработок приложений системы; • проект конвертирования данных; 9 90 • проект настроек приложений; • техпроект инфраструктуры; • проект организационной структуры; • среда для выполнения доработок конвертирования данных. приложений и Таблица 1.8. Состав работ стадии «Техническое проектирование» по этапам Этап Работы С1. Планирование технического проектирования РМ1. Планирование проекта и стадий (С) ОD4. Организация работ на объекте (С) С2. Проектирование приложений ID3. Реализация инфраструктурных подсистем AD1. Доработка или адаптация программ (С) AD2. Конвертирование данных (С) BR3. Отражение бизнес-требований (С) СЗ. Проектирование инфраструктуры SE3. Планирование вычислительных ресурсов (С) ID1. Проектирование информационной инфраструктуры (С) ID2. Подготовка среды проекта (С) С4. Проектирование организационной структуры ОD1. Организационное проектирование (С) С5. Разработка технического проекта DО2. Разработка проектной документации (С) С6. Завершение технического проектирования РМ3. Завершение стадии и проекта (С) Рекомендации по выполнению работ Этап С 1. Планирование технического проектирования При организации работы группы внедрения необходимо создать среду для возможного прототипирования и использования прототипа для согласования проектных решений. Этап С 2. Проектирование приложений На основании созданного на стадии «Системное проектирование» прототипа и замечаний ключевых пользователей уточняются функциональные требования. Начальные данные вносятся в прототип. С прототипом работают 1 9 91 ключевые пользователи для выяснения дополнительных требований, согласно которым производится тонкая настройка прототипа. Проектирование приложений является основой технического проектирования системы. Этих работ может и не быть (отсутствие доработок, использование ТПР). В данном случае имеет смысл объединить стадии (С + D) в одну «Реализация АС». Этап С З. Проектирование инфраструктуры Информационная инфраструктура — это вычислительная, транспортная и физическая среды. Для создания специальных инфраструктурных подсистем и выполнения строительномонтажных работ вам, скорее всего, потребуется привлечь подрядные организации. Сроки выполнения подрядных работ должны быть увязаны с «Планом-графиком проекта». Для проектирования инфраструктуры нужно предоставить заказчику следующие исходные данные: • структуру (состав элементов) системы; • требования к техническому обеспечению; • требования к вычислительному, транспортному и физическому слоям инфраструктуры; • требования к информационному обмену между компонентами системы; • требования к хранению, восстановлению, контролю данных; • требования к надежности (если есть); • план загрузки мощностей системы; • план подготовки объекта к вводу системы в действие; • план-график проекта, включающий даты готовности инфраструктурных подсистем; • план размещения приложений и БД. Вся перечисленная информация должна быть в ТЗ. Этап С 4. Проектирование организационной структуры Разработка решений по организационной структуре должна выполняться в соответствии с требованиями ТЗ к персоналу и регламенту АС. 2 9 92 Необходимо закрепить функции («роли») пользователей за подразделениями и должностными позициями. Решения по организационной структуре отражаются в пояснительной записке или в отдельном документе «OD.003 Описание организационной структуры» (см. ГОСТ). Этап С 5. Разработка технического проекта Технический проект — комплект проектных документов, описывающих принятые для выполнения технических требований проектные решения. На основе техпроекта осуществляется реализация (построение) системы. Этап С 6. Завершение технического проектирования Подводятся итоги стадии, оценивается качество выполненных работ, высвобождаются использованный персонал и инфраструктура (рис. 3.6). Работы стадии «Реализация АС» могут быть начаты до окончания технического проектирования, но только по документально согласованным частям (например, отдельным заданиям на разработку). 3 9 93 Рис. 1.6. Этапы работ стадии «Техническое проектирование» Выходные документы • описание среды реализации; • пояснительная записка к техническому проекту; • акт приемки-сдачи. Отличия при использовании ТПР При наличии ТПР трудоемкость разработки техпроекта и проектных решений уменьшается на величину готовых разработок. Описания проектных разработок могут вставляться в проектную документацию в виде готовых документов. Если вы строите систему только с помощью ТПР, стадию «Техническое проектирование» можно исключить из проекта. Стадия D. Реализация АС Цели стадии Результатом «Реализации АС» должно стать достижение следующих целей: 4 9 94 1. Готовность протестированных программных разработок, включая: доработки программных приложений, интерфейсные программы, программы конвертирования данных, смежные интегрируемые программы. 2. Подтвержденное соответствие производительности системы. 3. Завершенность запланированных оргструктурных мероприятий. 4. Готовность требуемых инфраструктурных подсистем. 5. Готовность эксплуатационной документации. 6. Готовность программы и методики испытаний. 7. Готовность среды для проведения испытаний. 8. Готовность средств и среды обучения пользователей. 9. Обученные ключевые пользователи. 10. Завершенность сборки, проверки и выпуска системы. Таблица 1.9. Состав работ стадии «Реализация АС» по этапам Этап Работы D1. Планирование реализации РМ1. Планирование проекта и стадий (D) ОD4. Организация работ на объекте (D) D2. Реализация приложений AD1. Доработка или адаптация программ (D) AD2. Конвертирование данных (D) D3. Реализация инфраструктуры SE3. Планирование вычислительных ресурсов (D) ID2. Подготовка среды проекта (D) ID3. Реализация инфраструктурных подсистем D4. Разработка эксплуатационной документации DО3. Разработка эксплуатационной документации D5. Реализация организационной структуры OD1. Организационное проектирование (D) ОD3. Подготовка персонала D6. Сборка АС ST1. Регламентирование тестирования (D) SE4. Сборка системы 5 9 95 SE5. Комплексная наладка ST3. Тестирование производительности D7. Завершение реализации РМ3. Завершение стадии и проекта (D) Рекомендации по выполнению работ Этап D 1. Планирование реализации Состав работ первых трех стадий в значительной степени предопределен структурой разрабатываемых на них проектных документов: отчет об обследовании, ТЗ, пояснительная записка к техническому проекту. Особенностью стадии «Реализация АС» является сложность использования типовых планов работ, поскольку состав работ специфичен для каждого объекта и в значительной степени определяется составом программных доработок. Объем работ на разных объектах также может сильно отличаться. Этап D 2. Реализация приложений Отслеживание состава доработок Необходимо строго отслеживать состав выполняемых доработок. Любая попытка навязать выполнение не предусмотренных проектом работ должна пресекаться менеджером проекта. Допускаются замены одного вида доработок другими, не более трудоемкими. Этап D 3. Реализация инфраструктуры Кроме создания эксплуатационной среды АСУП нужно контролировать создание среды для испытаний системы и обучения пользователей. Это не всегда одно и то же. Например, при большом количестве пользователей может потребоваться учебный класс или проекционное оборудование. Этап D 4. Разработка эксплуатационной документации Эксплуатационные документы предназначены для организации эффективного и безопасного использования системы по назначению и обеспечения надежности ее функционирования. Основные эксплуатационные документы должны позволять идентифицировать АС, вести инвентарный учет элементов системы, управлять ее конфигурацией, планировать развитие, интеграцию или утилизацию АС. 6 9 96 Часто по результатам стадии «Реализация АС» требуется выпустить описательную документацию — аналог исполнительной документации в строительстве. Реализованная система может отличаться от проектной конфигурации, описанной в техпроекте, на уровне деталей. Такие изменения могут быть внесены, например, по результатам испытаний. Этап D 5. Реализация организационной структуры В соответствии с требованием ТЗ внутри компании разрабатывается и публикуется вся необходимая организационнометодическая документация: должностные инструкции, положения о структурных единицах, процедуры процессов, политика безопасности и т. п. Обучение проходят ключевые пользователи. Его полезно совмещать с настройкой приложений прототипа. Ключевые пользователи обучаются функциональности системы в группе внедрения под руководством менеджера проекта. Обучение общего характера (например, по изучению программной платформы в учебном центре) может быть начато как угодно рано (например, на стадии «Системное проектирование»). А завершить его можно лишь на стадии реализации, когда структура пользователей становится известна полностью (на уровне персоналий). Обучение конечных пользователей необходимо начинать после готовности ключевых пользователей (независимо от текущей стадии) и заканчивать на стадии «Ввод в действие» как можно позже, перед опытной эксплуатацией, чтобы исключить изменение организационной структуры, в составе персонала и утрату (забывание) пользователями навыков работы с системой. Обучение конечных пользователей производится силами ключевых. Этап D 6. Сборка АС Документ «Программа и методика испытаний» (ПиМ) разрабатывается в соответствии с требованиями к тестированию АС, прописанными в ТЗ. В документе определяются этапы испытаний; документы, разрабатываемые на всех этапах; представляются методика и 7 9 97 сценарии тестирования АС. Основная задача разработки ПиМ — обеспечить тестовое покрытие для всех функций системы. При этом надо указать не только способы проверки каждой функции, но формальные критерии выполнения тестов, условия проведения испытаний и тестовые наборы данных. Виды испытаний АСУП: • Предварительные испытания — проводятся для доказательства работоспособности системы и подтверждения ее комплектности на момент запуска в опытную эксплуатацию. Цель предварительных испытаний — предотвратить остановку системы после начала опытной эксплуатации для ее доработки. • Опытная эксплуатация — проводится для проверки соответствия созданной системы требованиям, предъявленным к ней в ТЗ. Это обязательный вид испытаний. Его задачей является переход к промышленной эксплуатации без остановки системы. • Приемочные испытания — проводятся для подтверждения готовности эксплуатируемой в опытном режиме системы к промышленной эксплуатации. Содержание испытаний описано в разделе «Рекомендации по выполнению работы» (стадия «Ввод в действие»). На данном этапе осуществляются комплектация и сборка системы: все элементы устанавливаются в реализованной инфраструктуре в необходимой конфигурации, выполняется локальная пуско-наладка (рис. 3.7). Фактические комплектность, конфигурация, результаты наладки регистрируются соответствующими записями комплектации и наладки. Должны быть документированы комплектность, версии, дислокация и настройки всех элементов системы. Собранная система подвергается комплексной наладке («сквозной пример»). Данные для «сквозного примера» следует подготовить заранее. Комплексную наладку можно совмещать с предварительными испытаниями, если временной отрезок между стадиями «Реализация АС» и «Ввод в действие» невелик, а 8 9 98 испытания проводит тот же персонал (группа внедрения), что и комплексную пуско-наладку. Во время пуско-наладки необходимо полностью убедиться в работоспособности системы и возможности ее приемки в опытную эксплуатацию. В ней должны принимать участие ключевые пользователи и обслуживающий персонал. Особое внимание надо уделять согласованности работы всех компонентов системы. По результатам пуско-наладки могут быть внесены изменения в эксплуатационную документацию. При необходимости, если производительность ключевых функций АС является критичным параметром (требования ТЗ), может проводиться дополнительное тестирование производительности системы — в соответствии со специально разрабатываемыми требованиями и по спецпрограмме в конце стадии «Реализация АС». Этап D 7. Завершение реализации На основании записей комплектации и наладки, эксплуатационной документации и факта выполнения комплексной пуско-наладки подписывается акт приемки-сдачи работ по стадии «Реализация АС». По результатам стадии принимается решение о приемке системы в опытную эксплуатацию. На стадии «Ввод в действие» это решение должно быть закреплено соответствующим приказом. Изменение требований Необходимо отслеживать изменение требований к системе и проектных решений. Любое изменение возможно только после оценки его реализации и допустимости, внесения соответствующих поправок в спецификации проекта (в ТС и ТЗ — в виде дополнений). Все масштабные доработки, не включенные в проект и не отраженные в проектной документации (в том числе, если вы решили платить за них отдельно), должны выноситься за его рамки: на следующие проекты или период сопровождения. Выходные документы 9 99 • • • • • • • уточнения консультационной документации; журнал установки среды для тестирования; описание среды тестирования и обучения; программа и методика испытаний; разрешение на выпуск; акт приемки-сдачи; эксплуатационная документация. Рис. 1.7. Этапы работ стадии «Реализация АС» Управление конфигурацией Изменения, реализуемые в системе и ее элементах, надо отражать в соответствующей проектной и эксплуатационной документации. Информацию о существующей конфигурации системы необходимо поддерживать в актуальном состоянии. Перед выпуском системы надо проверить конфигурацию и версии всех 1 100 ее элементов, отразить актуальную комплектность в документе «Паспорт АС». Процесс эксплуатации Перед выпуском системы и до начала испытаний необходимо добиться, чтобы обслуживающий персонал вашей компании принял на себя обязанности, связанные с процессом эксплуатации системы: 1. Управление учетными записями и правами доступа пользователей. 2. Контроль соблюдения пользователями правил работы с системой и обучение, консультирование пользователей этим правилам. 3. Эксплуатационная настройка и наладка режимов работы системы. 4. Задание режимов, запуск и контроль выполнения регламентированных функциональных задач системы, выполняемых в пакетном режиме (резервное копирование, архивация, печать регламентированных отчетов, закрытие операционного дня и т. д.). 5. Мониторинг системных событий, контроль ключевых эксплуатационных показателей, анализ производительности и динамики изменений, происходящих в системе. 6. Выполнение регламентных работ по поддержке работоспособности системы, доступности ее функций, целостности и конфиденциальности информации. 7. Выполнение ремонтно-восстановительных работ при авариях и отказах системы; нарушении режимов ее работы; снижении степени защиты, надежности, безопасности, производительности или эффективности (за пределами установленного уровня). 8. Выполнение работ по плановому развитию и модернизации системы. Стадия Е. Ввод в действие Цели стадии Целью стадии является проверенная система, готовая к промышленной эксплуатации и включающая полный набор 1 101 эксплуатационной документации, обученный персонал, настроенные приложения и актуальные данные. На момент сразу после окончания работ стадии система обычно принимается в промышленную эксплуатацию. Для достижения цели стадии необходимо: 1. Завершить обучение пользователей. 2. Конвертировать или ввести актуальные данные. 3. Создать вместе с консультантами приемочную комиссию. 4. Утвердить «Программу и методику испытаний». 5. Провести испытания, исправить ошибки и устранить замечания. 6. Передать управление конфигурацией заказчику. 7. Закрыть договор. Подробнее работы и задачи стадии изложены в следующем подразделе. Таблица 1.10. Состав работ стадии «Ввод в действие» по этапам Этап Работы Задачи Е1. Планирование ввода в действие РМ1. Планирование проекта Планирование стадии Е: актуализировать РМ.001 и стадий (Е) РМ.014 ОD4. Организация работ на OD.013-OD.021 применительно к стадии Е: в объекте (Е) соответствии с новыми условиями. Повторение задач. OD.013 и OD.014 необходимо в связи с массовым привлечением персонала заказчика к работе с системой Е2. Подготовка испытаний ST1. Регламентирование ST.005 Создать приемочную комиссию. тестирования (Е) ST. 106 Издать и утвердить программу и методику испытаний ОD3. Подготовка персонала OD.012 Провести обучение пользователей. Обучение (Е) пользователей в зависимости от расчетной продолжительности может быть начато на предыдущих стадиях AD2. Конвертирование AD.023 Конвертирование и верификация данных данных (Е) 2 1 102 ЕЗ. Предварительные испытания ST2. Предварительные ST.006-ST.009 испытания Е4. Опытная эксплуатация ST4. Опытная эксплуатация ST.021 -ST.023. Задача ST.023 выполняется итерационно до полного устранения ошибок и принятых замечаний Е5. Приемочные испытания ST5. Приемочные испытания ST.024 Выполнить приемочные испытания Е6. Завершение проекта РМ3. Завершение стадии и Завершить стадию и проект: РМ.201-РМ.206 проекта (Е) Рекомендации по выполнению работ Этап Е 1. Планирование ввода в действие Особенностью стадии «Ввод в действие» является слабая формализуемость работ опытной эксплуатации. Дополнительную сложность представляет синхронизация окончания работ по обучению пользователей и конвертированию данных с началом испытаний. Однако если процедура конвертирования данных хорошо проработана и прошла должное тестирование, она не должна вызвать проблем. Качество и своевременность подготовки пользователей зависят от вас, а не от консультанта. Поэтому данный фактор вносит неопределенность в выполнение сроков работ и их результат. Наличие тщательно проработанной «Программы и методики испытаний» обеспечивает полноценное управление работами стадии «Ввод в действие». Этап Е 2. Подготовка испытаний Подготовка является наиболее ответственным и требующим повышенного внимания со стороны менеджера проекта этапом испытаний. От того, как выполнена подготовка, во многом зависит конечный результат. Работы по подготовке к испытаниям сводятся к обучению конечных пользователей и конвертированию, а также проверке данных. Придание правового статуса испытаниям Для проведения испытаний приказом генерального директора вашего предприятия создается полномочная 3 1 103 приемочная комиссия, обладающая, как правило, статусом совместной комиссии. Обычно в ее состав входят три-пять человек, в том числе один-два специалиста — от исполнителя и два-три — от заказчика. Председателем приемочной комиссии назначается председатель координационного комитета — представитель заказчика (из числа членов комиссии). Задачами приемочной комиссии являются: • принятие АС в опытную эксплуатацию с подписанием акта приемки в опытную эксплуатацию; • утверждение документа «Программа и методика испытаний»; • подготовка документа «Приказ о начале опытной эксплуатации» и организация испытаний; • отслеживание записей в документе «Журнал опытной эксплуатации» и ведение документа «Протокол тестирования»; • разработка документа «Протокол согласования»; • принятие решений по ходу и результатам испытаний; • приемка в промышленную эксплуатацию, подписание акта приемки в промышленную эксплуатацию. Приемочная комиссия утверждает программу и методику испытаний, организует испытания. Все дальнейшие решения по ходу испытаний подтверждаются приемочной комиссией. Обучение конечных пользователей Обучение конечных пользователей организуется и проводится вашими силами (при наличии бюджета можно привлечь подрядчиков) с использованием обученных ранее ключевых пользователей. Окончание обучения желательно максимально приблизить к началу опытной эксплуатации, чтобы пользователи не успели потерять приобретенные навыки. Начинать обучение нужно с учетом его расчетной продолжительности, заранее. При большом количестве конечных пользователей необходимо начинать обучение на стадиях «Реализация АС» или даже «Техническое проектирование», сразу после обучения ключевых пользователей. 4 1 104 Конвертирование данных Конвертирование данных в соответствии с планом конвертирования проводится группой внедрения. Эти данные проходят проверку. Необходимо обеспечить выполнение требований к конвертированию, изложенных в ТЗ. Предполагается, что все процедуры прошли тестирование, а конвертируемые данные проанализированы и приведены в соответствие с требованиями. При соблюдении перечисленных условий конвертирование не может потерпеть фиаско, а опытная эксплуатация начнется точно в установленный срок. Срыв начала опытной эксплуатации, как и остановка системы после ее начала, свидетельствует о плохой подготовке испытаний и низком качестве работы менеджера проекта. Этап Е 3. Предварительные испытания Предварительные испытания проводятся для подтверждения работоспособности системы и ее готовности к началу опытной эксплуатации. Предварительные испытания необходимы, чтобы не останавливать эксплуатацию системы после начала регистрации в ней учетных событий и работы с актуальными оперативными данными. Они проводятся на актуальных первичных данных. Однако предварительные испытания могут не осуществляться, если с момента комплексной наладки прошло мало времени и работоспособность системы не вызывает сомнений. Выявленные в ходе предварительных испытаний ошибки реализации должны быть устранены до начала опытной эксплуатации. Этап Е 4. Опытная эксплуатация Начало опытной эксплуатации фиксируется актом приемки в опытную эксплуатацию (ГОСТ) или приказом заказчика по предприятию. Минимальная длительность опытной эксплуатации — один месяц. Система работает в штатном режиме, то есть приложения установлены и настроены на всех клиентских станциях, 5 1 105 указанных в ТЗ. Пользователи системы работают с реальными данными и заносят свои замечания в журнал опытной эксплуатации. Во время опытной эксплуатации специалисты исполнителя дорабатывают систему в соответствии с появившимися требованиями и замечаниями, не противоречащими ТЗ. Устраняются выявленные ошибки реализации и конфигурации. То, что невозможно исправить в определенные договором сроки, оговаривается в протоколе согласования, где указываются: 1. невыполненные (неисправленные) к окончанию стадии «Ввод в действие» требования (замечания); 2. список требований (замечаний), которые не будут устраняться исполнителем; 3. сроки выполнения (исправления) тех требований (замечаний), которые должны быть выполнены (исправлены) после окончания приемочных испытаний. Этап Е 5. Приемочные испытания Приемочные испытания проводятся в соответствии с утвержденной программой и методикой испытаний (см. приложение 4). Приемочные испытания представляют собой официальное совещание (заседание) членов приемочной комиссии для согласованного подписания акта приемки АС в промышленную эксплуатацию. Технические мероприятия не проводятся. Заключение комиссией дается по представленным документированным результатам опытной эксплуатации системы (протоколу, журналу). Этап Е 6. Завершение проекта На координационном комитете подводятся итоги стадии и проекта, осуществляются измерение и оценка поставленных целей, оценивается качество выполненных работ. Управление конфигурацией системы полностью передается эксплуатационным службам вашей компании (если иное не оговорено в отдельных, уже подписанных на момент завершения проекта договорах вашей компании с внешними подрядчиками). 6 1 106 Составляется паспорт проекта. По результатам стадии вы должны будете самостоятельно принять решение о приемке системы в промышленную эксплуатацию. Систему запускает не консультант, а предприятие. Особые замечания и советы Цели целям рознь Не секрет, что целями автоматизации управленческого учета не могут являться цели внедрения управленческого учета. Автоматизация — один из этапов, пусть даже последний и решающий. Но автоматизации ради автоматизации не бывает. Цель руководителя предприятия не может заключаться во фразе: «Хочу, чтобы все было автоматизировано». Есть высшая цель, ради которой он стремится все автоматизировать. Например, получать реальную себестоимость выстраиваемых им квадратных метров жилья ежемесячно на второй день после окончания месяца, а не ежеквартально, как это происходит сейчас в результате использования сметных данных бухгалтерского учета. Поэтому существуют «бизнес-цели» и «цели автоматизации». Первые со вторыми необходимо связать, но никогда не смешивать (см. приложение 1 «Руководство по целеполаганию» ). О необходимости обследования Если вы действительно проектировали УУ, львиная доля работы по обследованию (и даже часть работ по системному проектированию) вами уже проделана. Но обследование все равно придется провести, так как консультантам нужно ознакомиться с вашими документами. Если вы внедряете систему самостоятельно, вам все равно не обойтись ни без методологии внедрения, ни без обследования собственной компании. Бизнес-процессы На данный момент вам может показаться, что руководство предлагает вам заниматься двойной работой: описывать БП как 7 1 107 на этапе проектирования УУ, так и на этапе технологического обеспечения (внедрения) УУ. Тем не менее, представленные инструкции по описанию БП не только на первый взгляд противоречат друг другу. Во-первых, проектирование и автоматизация УУ могут быть отдельными самостоятельными проектами. Выполнение одного из них не обязывает вас браться за другой. Можно спроектировать УУ в «минимальном» режиме, описывая только бизнес-функции. Тогда вам пригодится полноценное описание методологии внедрения АСУ П. Или, если вы все-таки описали во всех подробностях свои БП при проектировании УУ, вы сами сможете определить степень детализации их описания на этапе автоматизации. Зачастую между проектированием и внедрением УУ проходит определенное время, поэтому понятие «описание БП» во время внедрения вы можете заменить на «актуализацию описания БП». Кроме того, не стоит забывать, что исполнителями обоих этапов в 90% случаев являются разные консалтинговые компании. 8 1 108 Рис. 1.8. Этапы работ стадии «Ввод в действие» Сложность архитектурных уровней У системы управления есть множество инфраструктурных уровней: • сетевая; • информационная; • вычислительная; • прикладная; • инженерная; • организационная. Поэтому, приступая к созданию АСУП, необходимо решать архитектурные вопросы для каждого уровня. Сложность в том, что границы на различных уровнях между частями системы будут проходить в разных местах: функциональные подсистемы могут 9 1 109 иметь общие кабельные системы, использовать общие или выделенные сегменты сети, общие или выделенные вычислительные системы, базы данных, программные приложения. Может пересекаться и состав рабочих мест. Поэтому при планировании проекта или комплекса проектов следует увязывать решение всех инфраструктурных вопросов с учетом наследуемых мощностей, динамики морального и физического старения средств ВТ и ПО, развития предприятия, планов по развитию ИС и т. п. Пренебрежение этим приводит, как минимум, к нерациональному использованию средств и неэффективности АСУП. Два важных замечания о ТЗ Техническое задание — это не задание консультанту. ТЗ — свод требований к системе и планов по ее созданию (развитию). Это единственный технический документ, актуальность которого должна поддерживаться на протяжении всего проекта. Если бы ТЗ являлось заданием консультанту, его никто бы не читал и не актуализировал. Оно должно быть руководством для всех заинтересованных сторон, принимающих участие в проекте. И, кстати, ТЗ — единственный технический документ, легитимность которого подтверждает Гражданский кодекс РФ. На наш взгляд, разработчики ПО двигаются к тому, что техническое задание не является предметом целенаправленной реализации. Это не значит, что без него можно обойтись. Идеальный подход к внедрению системы, когда консультант реализует прототип, осуществляет окончательные настройки, проводит вместе с вами приемочное тестирование и по его результатам распечатывает из системы протокол текущих настроек. Этот протокол, при всей своей технологичности, будет для вас гораздо понятнее, чем ТЗ об абстрактной системе, функциональность которой подкреплена всего-навсего работой прототипа. Такое «протокольное» ТЗ необходимо, чтобы зафиксировать текущий набор настроек системы. Впоследствии при непредвиденных ситуациях можно обращаться к протоколу как к «конституции» АСУП. Фиксация нужна и для того, чтобы, 1 110 самостоятельно используя систему, вы могли понять, что сделали не так и как вернуться в исходное состояние. При таком подходе существует одна, максимум, — две стадии, выводящие вас на режим опытной эксплуатации. К сожалению, пока его не могут осуществить и предложить все поставщики программного обеспечения, но будущее — за ним. Самостоятельное внедрение Статистика компании гласит: процент самостоятельного внедрения систем управленческого учета легкого и среднего класса равен где-то 30%, тяжелого класса — менее 10%. Это кажущаяся экономия — стоимость внедрения системы, особенно «тяжелой», в разы превышает сумму, затрачиваемую на лицензионное программное обеспечение. Казалось бы, все просто: обучить свой персонал и дать людям задание внедрить компьютерную систему. На деле все сложнее. Ни одни курсы не дают представления о том, что система действительно может. В наш век, когда новые версии программного обеспечения выходят регулярно, практически все системы грешат, например, отсутствием полного описания. Можно попробовать внедрить систему самостоятельно, но тогда вы не успеете подготовить ваших людей, которые будут полностью ответственными за внедрение. Это не значит, что они не справятся с поставленными задачами — не удастся лишь уложиться в заданные сроки. Одно из самых ценных свойств профессионала, не раз внедрявшего систему, в том, что он может предсказать, сколько времени займет тот или иной этап внедрения. Поэтому, как вы уже догадались, мы рекомендуем: для внедрения системы нужно привлекать профессионалов. Тестирование При внедрении легких и средних бизнес-приложений нередко используется следующий сценарий тестирования. В качестве примера берется пакет документов за какой-нибудь прошедший отчетный период. Необходимо оценить, насколько цифры, которые «выдает» система, совпадают с цифрами этого периода. Минусы данного сценария заключаются в том, что, во1 111 первых, документов, которые вам необходимо ввести в систему, может быть очень много, отчего сам процесс тестирования затянется надолго; и, во-вторых, имеющиеся цифры получены по итогам бухгалтерского учета, а вы строите систему управленческого учета. Поэтому в данном конкретном случае мы лишь проверяем, насколько правильно система считает ваши документы. Для оценки правильности построения системы управленческого учета приемочное тестирование равносильно учебному полигону. Вы можете смоделировать необходимую ситуацию, описать ее на бумаге и поработать в заданном режиме. Тестированию подвергается не только конкретная отчетность и степень ее совпадения с вашими ожиданиями, но и сам процесс. На стадии приемочного тестирования вам необходимо понять, удобно ли пользоваться системой. В ходе этой стадии вы можете выяснить, что те или иные функции, которые вам изначально казались простыми, в системе сложны, и эта сложность превалирует над необходимостью автоматизации функций как таковых. То есть затраты на автоматизацию гораздо выше полученного от нее эффекта. Про эффективность, в том числе экономическую, от внедрения системы мы поговорим. Несостоятельным является тезис «лучше перетестировать, чем недотестировать». Излишнее тестирование приводит к бессмысленным тратам: надеясь на выявление всех ошибок при последующем масштабном тестировании, разработчик просто будет снижать качество своей работы. Дополнительные требования На стадии технического проектирования и последующих в 80% случаев возникают дополнительные требования к разрабатываемой системе. Потому что только начиная с этих стадий вы реально знакомитесь с системой. Кроме того, бизнес, конъюнктура рынка и прочие условия (читай — ваша компания) к этому времени могут измениться. Число дополнительных заданий на разработку не должно превышать определенного порога от функционала, который изначально был заложен в систему. Вернее, не превышать процента, который вы 2 1 112 спрогнозировали с консультантом. На российском рынке нормальный процент доработок бизнес-приложения класса ERP равен 20%. Сколько платить за опытную эксплуатацию Главным показателем завершения опытной эксплуатации является тот факт, что вы уже овладели системой и больше не нуждаетесь в услугах консультантов. В связи с этим самостоятельная эксплуатация системы стимулирует вас как можно быстрее и лучше ею овладевать. При этом за фазу опытной эксплуатации вы платите гораздо меньше. Кстати, многие консультанты высоко оценивают период опытной эксплуатации. Это связано с тем, что ввиду неопределенности будущего функционала системы они закладывают инвестиции на покрытие своих рисков (непредвиденных ошибок) за ваш счет. Подумайте о таком сценарии, если вы не пользуетесь сопровождением в ходе опытной эксплуатации. Впрочем, это не значит, что если по вине консультантов возникают ошибки, они не должны приехать и все исправить. Как запустить систему? Самым правильным запуском является одновременный запуск всех настроенных функций. Потому что управленческий учет — это учет одного дня, а системы автоматизации управленческого учета — системы одного «операционного» дня. Разрывая этот цикл и внедряя, скажем, сначала логистику, потом финансы, вы вынуждены дезинтегрировать заведомо интегрированную систему. Работы по дезинтеграции стоят времени и денег; обратная интеграция, когда вы «довнедряете» оставшиеся бизнес-функции, — тоже. Решите, стоит ли вам доплачивать за лишние операции. Кроме того, настоящий консультант должен уметь запускать для вас систему в комплексе. Это довольно сложно — требует напряженной, иногда — ночной работы; трудозатрат десятков и сотен ваших сотрудников. Но отдачей являются время, нервы и деньги, которые вы в результате сэкономите. Да и оценить завершенность системы можно лишь, если она работает целиком. Тестируя отдельный кусок системы, 3 1 113 вы не всегда можете определить сторону, виноватую в том, что результат не соответствует вашим ожиданиям. То ли это ошибки консультантов, то ли в системе нет предполагаемых функций, то ли задача была поставлена некорректно. Еще раз о прототипе Прототип — необязательно полностью настроенная система. Это может быть «игровая настройка» приложения, с достаточной степенью наглядности позволяющая продемонстрировать любую из заложенных в ней и ожидаемых функций (за исключением еще неразработанных). Вы должны сами сформулировать необходимую и достаточную степень наглядности — как система будет выглядеть. Например, ввод счета к оплате. В будущей системе вы ожидаете, что у вас будет пять аналитических признаков, а в прототипе их только три. Появление двух дополнительных аналитических признаков — это, как говорится, дело техники. И не забывайте, что прототип необходимо использовать на протяжении всей разработки вплоть до окончания реализации. О методологии вендора У каждого крупного и серьезного разработчика бизнесприложений есть своя методология внедрения. Ее использование имеет свои плюсы и минусы. Рис. 1.9. Сравнение методик проектирования 4 1 114 Минус. «Вендорская» методология нацелена на внедрение бизнес-приложения вендора. Следовательно, в случаях, когда вы строите систему, состоящую из бизнес-приложений нескольких производителей, она неприменима. Кроме того, методики производителей «малых» и «средних» приложений зачастую не содержат в себе описания работ по разработке инфраструктурных слоев системы. Плюс. Если что-то пошло не так, и вы не можете наладить продуктивное сотрудничество с консультантом, применение «вендорской» методики позволит вам воспользоваться услугами того же вендора или независимой аудиторской компании в ходе аудита вашего проекта. Более того, вы можете заказать у разработчика контроль качества вашего проекта, чтобы всегда быть уверенным — консультант все делает правильно. Очевидно, что такую услугу вендор может оказывать, только если вы используете его фирменную методологию внедрения. Кстати: всегда нужно говорить об обеспечении (и/или управлении) качества, а не о его контроле. Контроль недостаточен и сам по себе в большом проекте малоэффективен. С точки зрения управляемости, бывает очень полезно разбить проектирование большой системы на проекты внедрения отдельных очередей. Например, автоматизация управления цепочками поставок, автоматизация управления сбытом и т. п. А если вам предстоит нелегкая задача управления сразу несколькими проектами, это уже программа. Поэтому в данном разделе не рассматривается такое понятие, как «очередь» системы, то есть функциональная подсистема АСУП. Не рассмотрены здесь и вопросы, касающиеся системного и процессного подхода к управлению ИТ на предприятии. Эти подходы — основа современного менеджмента (отражено во всех стандартах). Проект по созданию АСУП — лишь первый шаг, который нужно предпринять в череде процессов, связанных в единый жизненный цикл ИТ на предприятии. 5 1 115 Зависимость необходимости в автоматизации от зрелости компании В какой момент своего развития компания нуждается в том или ином инструменте автоматизации управленческого учета? Как зависит выбор методологии внедрения бизнес-приложения от степени зрелости вашей фирмы? Развитие компании хорошо показано на диаграмме, составленной «Harvard Business Review» (рис. 1.10). Здесь отображены пять фаз зрелости (размера). Рис. 1.10. Стадии зрелости организации В целях наглядности примерные сроки возникновения необходимости в автоматизации той или иной управленческой задачи показаны в табл. 1.11. 6 1 116 Таблица 1.11. Соотношение фаз развития организации и необходимости в автоматизации Фаза Фаза 1 Фаза 2 Фаза 3 Фаза 4 Фаза 5 Основные решаемые развития: задачи Стиль творче- направ- делеги- коорди- сотрудниуправления: ство ление рование нация чество Кризис лидер- автоноконбюрокрауправления: ство мия троль тизм 1 Управленческое планирование Стратегическое управление Управление по системе KPI (score carding) Сценарное планирование Бюджетное управление Финансовая консолидация Управленческий контроль Управленческий анализ Трансформация финансовой отчетности 2 Учет Ведение бухгалтерского учета Ведение финансового учета Конверсия финансовой отчетности 3 Управление ресурсами предприятия X X X X X X X X X X X X X X X X X X X X X X X X X 7 1 117 Финансовый контроллинг Калькуляция себестоимости ГП Управление закупками Управление НСИ Управление складами Управление реализацией продукции Взаимоотношения с заказчиками Маркетинг Электронная коммерция Производственное планирование Цеховое управление Управление проектами Кадры 4 Управление цепочками поставок Транспортное управление Цепочки поставок Взаимодействие с поставщиками Взаимодействие с дистрибьюторами Электронный обмен документами 5 Управление неструктурированно й информацией Организационнораспорядительный документооборот Договорной документооборот Управление корпоративным порталом X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 8 1 118 Управление знаниями Управление конструкторскими работами X X X X Главным риском фазы «Делегирование» является «Контроль». Именно на этой фазе развития обычно приступают к автоматизации функций управленческого планирования, оперативного учета и т. д. Если вы находитесь в фазе два («Направление»), максимум, что вам потребуется — внедрение «легкой» учетной системы. Дойдя до фазы «Делегирование», вы почувствуете потребность в бюджетном планировании и сможете надстроить уже имеющуюся у вас систему учета системой класса ВРМ. Фаза четыре («Координация») — время для принятия решения в пользу серьезной комплексной системы. На этом этапе многие компании начинают менять «легкое» учетное приложение на более «тяжелую» ERP-систему. И, поскольку на постановку и внедрение УУ обычно отводится большой срок, за время этого проекта компания переходит в фазу «Сотрудничество», находиться в которой без автоматизированного управленческого учета просто невозможно. Методология внедрения на фазах с первой по третью носит так называемый «экстремальный» характер. Внедрение разбивается на участки: отдел закупок, коммерческий департамент, АХО и т. п. На каждом участке производятся следующие работы: 1) обследование — интервью экспертов участка; 2) настройка и приемка прототипа — приемка фиксируется протоколом, в котором перечислены все настройки прототипа. Впоследствии протокол послужит аналогом технического задания; 3) окончательная настройка приложения для участка; 4) опытно-промышленная эксплуатация — системой начинают пользоваться сразу, полагаясь на поддержку внешних консультантов или собственных программистов. 9 1 119 Как вы уже поняли, управленческий учет связывает сотрудников организации в едином информационном пространстве, бюрократизирует и автоматизирует процессы. По сути, автоматизация — это «продвинутая» бюрократизация взаимодействия субъектов учета между собой. Известны случаи, когда фирма, находясь в фазе «Координация», кризисным риском которой является бюрократизм, страдает от того, что она не приемлет бюрократию как таковую по отношению к проектам автоматизации УУ. То есть делается попытка осуществить внедрение без составления необходимых документов. Так вы становитесь заложником ситуации, когда цели не задокументированы; общее понятие ожидаемого от внедрения УУ эффекта не зафиксировано; знаний людей, настраивающих систему, может не хватить. Такие внедрения проваливаются, в лучшем случае став не инструментом управления предприятием, а еще одним приложением, похожим на программу бухучета. Описания фаз Первая фаза, характеризующая маленькие и молодые компании, подразумевает стиль управления, основанный на творчестве. Главным движущим фактором являются идеи, рожденные в голове лидера компании. Лидерство и становится источником кризиса: неправильная идея принадлежит именно ему; больше ничьи идеи не воспринимаются, а если и берутся в расчет, то интерпретируются лидером по-своему. Вторая фаза характеризует компании более крупные и зрелые. Стилем управления в них является уже не поидейная реализация, а задание определенного направления развития. С этого момента возможным источником кризиса управления является желание, а иногда — обусловленная обстоятельствами необходимость автономизации тех или иных участков. У организации появляются филиалы или удаленные подразделения, поскольку она вынуждена вести бизнес в регионе, где она не представлена. Это тоже может явиться источником кризиса, потому что территориальное раздробление в растущей компании 2 1 120 приводит к тому, что каждый отвечает только за себя. Из-за этого начинаются отклонения от заданного направления. Третья фаза — более крупная и зрелая в плане возраста компания. Видны первые признаки делегирования полномочий от первого лица или от узкого круга первых лиц к наемным сотрудникам. Главный риск делегирования — появление контроля. Если раньше все было в одних руках, отныне люди приобретают власть, но, возможно, не обладая достаточной квалификацией, чтобы ею воспользоваться. Четвертая фаза — управление сводится к координации. Первое лицо компании занимается тем, что координирует между собой достаточно большое количество непосредственных подчиненных. Восемь, девять, пятнадцать заместителей генерального директора — достаточно большая команда, чтобы на ежедневной, ежечасной основе заниматься их координацией. На данном этапе происходит бюрократизация процессов. Компания неминуемо обрастает инструкциями, положениями, регламентами, следовать которым необходимо. Они помогают лидеру организовывать взаимодействие своих подчиненных. Пятая фаза — это сотрудничество. Оно наступает, когда в фирме вполне осознанно появляются такие институты, как совет директоров, дочерние предприятия, самостоятельные филиалы и т. д. Е. Плаксенков: «Управленческий учет есть в любой компании. Если его все-таки нет, значит, отсутствует понятие «системный бизнес». Работа ведется по «шуточному» принципу: купил-продал-израсходовал. Это спонтанный и недолгосрочный бизнес. Даже на самых ранних стадиях развития в компании есть управленческий учет. Прежде чем начинать реальный и системный бизнес, необходимо продумать финансовую сторону. С этого момента и появляется управленческий учет — вместе с желанием построить свое дело. Ведь любое желание неминуемо имеет финансовую сторону. Если бизнес поставлен на долгосрочной основе, в нем есть управленческий учет. 2 1 121 В нашей компании работает стандартизированная система, и это достаточно весомый показатель работоспособности и эффективности управленческого учета. Сотни людей — программистов, финансистов, менеджеров, других участников финансовых процессов — обучились, поняли и прочувствовали его специфику». Система УУ может появиться в компании на любой из перечисленных фаз. Теоретически. А практически отсутствуют случаи, когда подобная система возникала бы на первой фазе. Плановая часть управленческого учета может появиться лишь на третьей фазе. Ведь УУ позволяет распределять полномочия, а бюджетное планирование, бюджетирование синонимичны делегированию. Управленческий учет связывает сотрудников организации в едином информационном пространстве, бюрократизирует и автоматизирует процессы. Автоматизация — это, можно сказать, продвинутая бюрократизация взаимодействия друг с другом. Поэтому если вы находитесь на второй фазе, максимум, что потребуется — внедрить «легкую» учетную систему. На третьей фазе возникает необходимость в бюджетном планировании. Четвертая фаза — время для принятия решения в пользу серьезной комплексной системы. На этом этапе многие компании меняют «легкую» систему ERP на более «тяжелую». Методология внедрения пока экстремальная, то есть вы не проходите все четыре этапа — они сокращены до двух: принимается прототип, генерируется и подписывается ТЗ, и дальше — опытная эксплуатация. Пятая фаза — на данной ступени все зависит от продукта и от консультанта. По своему опыту знаю, на данной фазе развития компании проходят серьезный, минимум, четырехэтапный алгоритм внедрения систем автоматизации УУ. Конец третьей лекции Все замечания и предложения отсылайте по адресу: feedback@rfei.ru. 2 1 122