Комплексные системы управления изменяют бизнес-модель

<BR><BR>Боязнь ломки привычной модели управления предприятием зачастую становится препятствием для внедрения комплексных информационных систем.<BR>Петербургским менеджерам сложно смириться с тем, что выстраданная годами бизнес-модель может измениться в угоду алгоритмам, заложенным в автоматизированной системе управления. Эту проблему комментируют специалисты, опрошенные корреспондентом "ДП".<BR>"Все информационные системы гибкие и все настраиваются, но вот степень открытости должна быть такова, чтобы, не ломая основ, можно было приспособиться к любым бизнес-процессам. Порой изменение бизнес-процессов необходимо. Но это только на основе консенсуса, нужны хорошие внедренцы, хорошие продавцы, которые умеют убеждать.<BR>Два примера наших проектов по управлению персоналом. "Первомайская Заря": в результате обследования предложены изменения в системе оплате труда, которые с радостью были приняты.<BR>Но это только потому, что клиенту они понравились. "Ижорские заводы": наоборот, их требования по автоматизации сдельной оплаты труда с радостью приняты нами, потому что они разумны и положительно влияют на развитие системы в целом".<BR>"Проблемы изменения бизнес-процесса заказчика при внедрении действительно достаточно непросты. Это одна из тех причин, по которым проекты длятся так долго. Часто приходится менять не только бизнес-процесс, но и идеологию, подход к внедрению в производство.<BR>Единственный способ, на мой взгляд, -- показать руководству предприятия, как это можно сделать, что они от этого получат, как они сэкономят время и деньги и т.д. В большинстве случаев клиенты на это соглашаются. Но, естественно, это происходит не быстро".<BR>"Мне никогда не приходилось сталкиваться с какой-то проблемой, чтобы нужно было сильно сломать программу под конкретного заказчика или, наоборот, заказчик должен был "сломаться" под программу.<BR>Мы работаем достаточно гибкими средствами, которые позволяют решить большинство проблем или позволяют найти способ, как обойти какую-то возможную проблему.<BR>Во всяком случае, говорить заказчику "нет" приходилось только в том случае, если его просьба, достаточно простая и понятная, могла повлиять на что-нибудь еще (например, несоответствие ведения учета одного модуля и другого; могли, допустим, не пройти какие-то взаиморасчеты).<BR>Если говорить о доработке какого-то готового софта, то она не может превысить 10-20%. То есть разработать с каким-то конструктором отчет, добавить какие-то реквизиты к чему-то, не более.<BR>Если же продукт не подходит, скажем так, на 30%, то, как правило, он пишется заново, потому как переделывать его практически не имеет смысла".<BR>"Можно разделить проблему на две составные части, когда есть формальный подход приведения проекта и неформальный. Формальный -- это жесткое предварительное документирование всех процессов и согласование или с руководством предприятия, или с рабочей группой предприятия-заказчика того, что же будет результатом автоматизации на предприятии. Мы описываем сначала те процессы, которые есть, и показываем, как они будут выглядеть, когда будет установлена автоматизированная система. А неформальный подход -- когда такая документация не ведется, и мы -- либо за кружкой чая, либо за бутылкой коньяка -- договариваемся полюбовно, как мы делаем. Они соглашаются работать на том, что есть, или мы соглашаемся доработать то, что им нужно.<BR>Почему я разделил эту проблему? При продаже проекта перед внедрением достаточно сложно объяснить, что какие-то службы могут сократиться. Например, предприятие является градообразующим: если сказать, что в результате автоматизации сократится машинописное бюро, а там десяток женщин, у которых есть дети и т.д., -- то, скорее всего, проект не будет продан. Мы об этом умалчиваем, продаем, а потом машинописное бюро, в общем-то, не нужно, потому что все документы начинают готовить службы, в которых установлены системы. И чем занять машинописное бюро -- это уже проблема руководителя. Мы можем подсказать, можем пригласить консалтинговую фирму. Если он сам догадается, он отправит их красить заборы или будет платить им пособие".<BR>"Консалтинг при выборе системы предприятию необходим, чтобы четко понять цели и задачи, которые оно собирается решить при внедрении.<BR>Я мало видел программных продуктов, которые внедрялись бы с реинжинирингом. Речь в основном идет об оптимизации документооборота.<BR>Никто из внедренческих компаний никогда не говорит о сокращении подразделений и переводе филиала из одного города в другой, чтобы бизнес стал эффективнее. Но если нас спросят, то, возможно, мы и порекомендуем сделать нечто подобное. Все наши рекомендации продиктованы опытом внедрений".<BR>"Если то, что предприятие хочет оставить, не влияет на какие-то серьезные вещи или алгоритм системы, то мы идем навстречу предприятию. Мы почти всегда фиксируем и говорим о том, что: вот вы настояли на этом, посмотрите через некоторое время, какой будет результат.<BR>У нас есть пример наших пользователей, где через год, через 8 месяцев мы возвращаемся к уже внедренному процессу и изменяем его в той конфигурации, которую когда-то мы предлагали. Но здесь была достигнута, во-первых, неконфликтность проекта, и требование об изменении бизнес-процесса шло уже не от нас, а от предприятия".<BR>"Когда мы брали систему "Галактика", то на самом деле еще не знали, что будем делать и как управлять процессом. Конечно, не настолько все было запущено; уже были какие-то наметки, иначе мы бы "Галактику" и не брали.<BR>Всегда хочется получить что-то готовое и выбрать какой-то свой путь развития. Но это получается не всегда. Особенно в связи с нашим законодательством, с его изменениями. Нам хочется расти, больше автоматизировать, чем увеличивать численность.<BR>Система помогла нам в том, что произошло сокращение управленческого персонала".