Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Подобные документы

    Классификация автоматизированных информационных систем. Классические примеры систем класса А, B и С. Основные задачи и функции информационных систем (подсистем). Информационные технологии для управления предприятием: понятие, компоненты и их назначение.

    контрольная работа , добавлен 30.11.2010

    Роль структуры управления в информационной системе. Примеры информационных систем. Структура и классификация информационных систем. Информационные технологии. Этапы развития информационных технологий. Виды информационных технологий.

    курсовая работа , добавлен 17.06.2003

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

    реферат , добавлен 05.01.2010

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

    реферат , добавлен 14.01.2011

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

    контрольная работа , добавлен 18.11.2009

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

    дипломная работа , добавлен 20.09.2013

    Предмет и основные понятия информационных систем. Базовые стандарты корпоративных информационных систем. Характеристика входящих и исходящих потоков информации. Основные понятия искусственного интеллекта. Обеспечение безопасности информационных систем.

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


    Первая и самая главная причина провала: некорректно поставленная цель для информационной системы .


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


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


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

    Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.

    Эффективные цели

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


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


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

    Техническое задание

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


    Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».


    Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ – списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1-2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.


    Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.


    Следующим важным документом для успешного выполнения работ является план-график работ.

    План-график работ

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

    Запуск системы в работу

    Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.


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


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


    В итоге мы получаем такие этапы запуска и внедрения системы:

    • Тестирование с привлечением сотрудников заказчика на реальных примерах;
    • Опытная эксплуатация с немедленным устраняем возникающих проблем;
    • Промышленная эксплуатация.

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

    Вопрос: «Кто осуществит внедрение информационной системы?», чрезвычайно важен в каждом из случаев запуска проекта автоматизации.

    Данный тезис неоспорим, по нескольким причинам:

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

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

    Внедрение информационных систем в основном происходит по одной из следующих схем:

      Внедрение осуществляет компания-внедренец;

    1. Собственный отдел информационных технологий;
    2. Привлекается фрилансер, который выполняет функцию руководителя проекта.

    Рассмотрим каждый вариант подробнее.

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

    Нюансы работы с крупной компанией внедренцем:

      Внедрение информационной системы поставлено на поток;

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

      Неудача на «небольших» проектах мало влияет на общую репутацию компании и отношения к таким проектам соответствующее;

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

      Стоимость услуг – самая высокая из всех рассматриваемых вариантов.

    Альтернативный вариант – небольшая компания:

      Проект может стать приоритетной задачей для специалистов компании;

      Для таких компаний на мой взгляд характерно проявление жадности. Так как сфера информационных технологий пока не является самой конкурентной отраслью экономики. Небольшие компании могут получить значительный проект по внедрению информационных систем. В то время как основные силы компании уже заняты на проектах, недостаток пытаются восполнить ускоренным набором новичков, естественно желая сэкономить на зарплатах. Разработку передают самым дешевым аутсорсерам, тогда как сами за час работы программиста берут достаточно много. Маржа может достигать 75%. Эти проекты характеризуются постоянной сменой руководителя, чехардой консультантов, странными техническими решениями, срывом сроков.

      Успех проекта полностью зависит от квалификации сотрудников компании и в первую очередь менеджера проекта;

      Обходятся значительно дешевле чем.

    Собственный отдел информационных технологий (ИТ).

    На первый взгляд кажется оптимальным вариантом, свои сотрудники, контролируемые затраты, гарантия сохранения информации. Однако мировой опыт говорит случаи реализации проектов внедрения информационных систем таким методом – единичны! Характерным элементом таких проектов являются затянутые сроки реализации, причем затянутые на годы. Такие проекты переходят в операционную деятельность.

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

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

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

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

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

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

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

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

    Делая выводы из всего вышесказанного, хочется зафиксировать:

    • Привлечение крупной компании внедренца – прерогатива крупных компаний, успех проекта с которыми будет иметь имиджевую составляющую для внедренца;
    • Небольшая компания лучше подходит для не самых крупных внедрений, однако надо чутко следить за ходом внедрения информационной системы;
    • Внедрение силами собственного ИТ подразделения, при данной схеме крайне высок риск перевода проектной деятельности в операционную, проект будет длится годами, а цели будут постоянно меняться;
    • Фрилансер – интересный подход к реализации, но требует кропотливого подхода к выбору персоны консультанта. К сожалению, руководителям инициировавшим внедрение информационной системы трудно определить уровень компетентности ИТ специалиста, ввиду отсутствия опыта проектной деятельности в ИТ сфере. Кроме того, ключевым фактором данной схемы может быть уровень возлагаемых на специалиста компетенций.

    Исходя из того, что предложенные способы не идеальны.

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


    Первая и самая главная причина провала: некорректно поставленная цель для информационной системы .


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


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


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

    Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.

    Эффективные цели

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


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


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

    Техническое задание

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


    Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».


    Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ – списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1-2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.


    Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.


    Следующим важным документом для успешного выполнения работ является план-график работ.

    План-график работ

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

    Запуск системы в работу

    Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.


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


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


    В итоге мы получаем такие этапы запуска и внедрения системы:

    • Тестирование с привлечением сотрудников заказчика на реальных примерах;
    • Опытная эксплуатация с немедленным устраняем возникающих проблем;
    • Промышленная эксплуатация.

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

    Теги: Добавить метки





    Содержание


    Введение

    3

    Цели и задачи внедрения информационной системы

    4

    Классификация информационных систем

    6

    Требования к информационной системе

    9
    Проектирование и создание информационных систем

    10

    Внедрение информационных систем

    13

    Традиционный подход


    14

    Инновационный подход


    16

    Оценка эффективности

    18

    Опыт использования информационных систем

    19

    Список использованной литературы

    21

    Введение

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


    • выясняется, что показатели и процедуры, которые ранее использовались для анализа и планирования деятельности предприятия (например, объем произведенной продукции) не позволяют успешно конкурировать;

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

    В последнее время отчетливо проявляется стремление перехода компаний от детального управления внутренней деятельностью к управлению заказчиками и поставщиками. Конкурентоспособность компании все больше зависит от способности создавать и углублять взаимоотношения с другими компаниями (партнерами, конкурентами, заказчиками или поставщиками). Причинами этого являются:


    • расширение экономического пространства, на котором функционируют предприятия;

    • появление нового стратегического ресурса - информации;

    • необходимость учитывать фактор времени.

    Цели и Задачи информационной системы

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

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


    • снижение общих затрат предприятия в цепи поставок (при закупках),

    • повышение скорости товарооборота,

    • сокращение излишков товарных запасов до минимума,

    • увеличение и усложнение ассортимента продукции,

    • улучшение качества продукции,

    • выполнение заказов в срок и повышение общего качества обслуживания заказчиков,

    Основными целями автоматизации деятельности предприятия являются:


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

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

    • Автоматизация процессов, обеспечивающих выполнение основной деятельности.

    Для того, чтобы реально оценить эффективность системы, очень важно понимать какие задачи может решать правильно разработанная информационная система:


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

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

    • Управление финансами . Как правило, это ведение бухгалтерии, расчеты с дебиторами и кредиторами, учет основных средств, управление наличными средствами и планирование финансовой деятельности;

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

    • Управление затратами . Сюда относится учет всех затрат предприятия и калькуляция себестоимости готовой продукции или услуг;

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

    • Проектирование продукции и технологических процессов . Информация о составе продукции, технологических маршрутах ее изготовления, разработка продукции в соответствии с требованиями клиентов, а также оценка затрат, которые понесет предприятие при выпуске такой продукции.

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

    классификация Информационных систем

    Первые системы, которые были разработаны для решения задач управления на предприятии, в основном охватывали сферу складского или материального учета (IC – Inventory Control ). Их появление связано с тем, что учет материалов (сырья, готовой продукции, товаров) с одной стороны является извечным источником различных проблем для руководителя предприятия, а с другой (на предприятии относительно крупного размера) одной из самых трудоемких областей, требующих к себе постоянного внимания. Основной «деятельностью» такой системы является учет материалов.

    Следующий этап усовершенствования материального учета был ознаменован системами планирования производственных или материальных (в зависимости от направления деятельности организации) ресурсов. Эти системы, вошедшие в стандарт, а вернее два стандарта (MRP – Material Requirements Planning и MRP II – Manufacturing Requirements Planning ), очень широко распространены на Западе и давно и успешно используются предприятиями, в первую очередь производственных отраслей. Основные принципы, которые легли в основу систем стандарта MRP, включают


    • описание производственной деятельности как потока взаимосвязанных заказов;

    • учет ограничения ресурсов при выполнении заказов;

    • минимизацию производственных циклов и запасов;

    • формирование заказов снабжения и производства на основе заказов реализации и производственных графиков.
    Разумеется, есть и другие функции MRP: планирование цикла технологической обработки, планирование загрузки оборудования и т.д. На рис. 1 изображены процессы, которые реализуются при использовании такой системы:

    Рис. 1

    Следует отметить, что системы стандарта MRP решают проблему не столько учета, сколько управления материальными ресурсами предприятия.

    Наиболее популярным на данный момент новым видом информационных систем являются системы стандарта ERP - Enterprise Resource Planning . ERP-системы в своей функциональности охватывают не только складской учет и управление материалами, что в полном объеме предоставляют вышеописанные системы, но добавляют к этому все остальные ресурсы предприятия, прежде всего денежные. То есть ERP-системы должны охватывать все сферы предприятия, непосредственно связанные с его деятельностью. В первую очередь, здесь имеются в виду производственные предприятия. Системы данного стандарта поддерживают осуществление основных как финансовых, так и управленческих функций. Например, в системах Baan 1 – это:


    • финансы и бухгалтерия,

    • производство,

    • сбыт (включая складской учет, торговлю и маркетинг),

    • транспорт,

    • сервис и обслуживание оборудования,

    • управление проектами,

    • а также единая управленческая панель – модуль Информационная Система Руководителя, на которой руководитель может видеть все основные подразделения и производственные показатели.
    Рис. 2

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

    требования к информационной системе

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


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

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

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

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

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

    Проектирование и создание информационной системы

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

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


    • определиться с организационной штатной структурой,

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

    • произвести выделение основных технологических потоков (процессов),

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

    • на основании созданных механизмов управления сформировать технологию финансового анализа и управления деятельностью технологических потоков.
    Если будут иметься вышеперечисленные технологии, будет значительно легче разработать информационную систему. Однако, часто приходится упрощать бизнес процессы на предприятии, для того, чтобы было проще описать их на языке компьютеров.

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

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

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

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


    1. Проведение обследования с целью описания бизнес процессов организации.

    2. Разработка технического задания на систему автоматизации.

    3. Разработка технического проекта системы.

    4. Разработка системы (иногда называемая настройкой).

    5. Различные стадии и этапы внедрения, опытной и промышленной эксплуатации.

    6. Выполнение доработок в соответствии с изменившимися потребностями организации.
    Результатом проектирования системы является строго формализованное описание как объекта ее автоматизации, так и ее самой. Этот документ должен содержать описание того, с какой информацией должна работать система, каким образом представляются в ней данные и по каким правилам она работает.
    внедрение информационной системы
    Эффективность автоматизации деятельности предприятия, наравне с правильным проектированием и созданием системы, зависит от способа ее внедрения в организационную структуру компании. Обусловлено это психологическими факторами - обычно наблюдается сопротивление сотрудников созданию и использованию системы. Кроме того, внедрение системы может длиться от 6 месяцев до 2-3 лет. За такой период могут произойти изменения внешних и внутренних факторов, влияющих на работу предприятия. Поэтому ожидания руководства по поводу результатов работы системы могут не оправдаться (так как они уже успеют измениться).

    Рис. 3


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

    Традиционный подход

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

    Рис. 4. Первый этап горизонтальной автоматизации:

    автоматизация уровня исполнителей.

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

    Рис. 5. Второй этап горизонтальной автоматизации: автоматизация уровня исполнителей и среднего звена управления.


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

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

    Второй подход к автоматизации деятельности предприятия основан на использовании адаптируемых инновационных систем – систем, “способных саморегулироваться в соответствии с изменениями внешних условий.” 3

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

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

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

    Рис. 7. Первый этап: автоматизация верхних уровней управления.


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

    Рис. 8. Второй этап: создание единого информационного пространства


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

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

    Оценка эффективности

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

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

    В реальности, оценка результативности внедрения производится по “средним отраслевым показателям” (industry average). Типичные средние результаты внедрения 4:


    • 15-25% увеличение производительности

    • 10-20% уменьшение складских запасов

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

    Конечно, можно просто взять формулу и посчитать норму возврата на инвестиции (Return on investment). Но это не даст полной картины, так как не все положительные результаты можно так просто выразить в денежных единицах: например, возможные стратегические выгоды для компании или степень удовлетворения клиентов. Тем не менее, данное утверждение не означает невозможность такой попытки. На самом деле, многие не поддающиеся количественному описанию выгоды можно перевести в реальные цифры. Например, способность быстрее составлять баланс может являться материальной выгодой. Выявление материальных выгод требует проведения анализа, включающего разбиение бизнес процессов и заданий на элементы, поддающиеся четкому описанию.

    Опыт использования информационных систем

    Многие крупные компании США и Европы уже несколько лет назад перешли на использование информационных систем стандарта ERP. Про страны Азии такого сказать пока нельзя. Большинство финансовых менеджеров азиатских компаний едва ли слышали о таких системах, не говоря уж об их внедрении. Хотя есть компании, которые решились перейти на ERP-системы.

    Разработчики информационных систем, в частности SAP, Baan, Oracle, PeopleSoft и J.D.Edwards, довольно агрессивно рекламируют свои продукты, что создает впечатление у плохо осведомленных в данной области людей впечатление, что эти программы способны решить все проблемы их компаний. Статистика же показывает, что большая часть попыток внедрить информационную систему окончились неудачами, большими потерями, либо банкротством. Например, руководство компании FoxMeyer утверждает, что ошибочное внедрение ERP-системы привело ее к банкротству. Компания обвиняет в этом создателей системы и консультантов. Такая же участь постигла и компании Dell Computer, Dow Chemical и Kellogg’s.

    Но существуют также примеры успешного использования ERP-систем. Так, например, телекоммуникационная компания Aliant заявляет, что проект по внедрению системы ERP был очень удачным. Ожидаемая норма возврата на инвестиции в данный проект составила 33%.

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

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

    Используемая литература


    1. Information System Management

    2. М. Хохлова, статья «Современный рынок систем управления предприятияем»

    3. Тезисы доклада компании Ally Information Technologies “Инструментальная поддержка адаптивного развития бизнеса”

    4. Д. Глямшин, статья «Выход из кризиса – система управления»

    5. С. Колесников, статья «Итак, системы автоматизации…»

    6. Исследование «Программы для бизнеса-98», АКДИ «Экономика и жизнь»

    7. Ю. Токарев, статья «Корпоративные информационные системы и консорциум разработчиков»

    8. М. Ильина, статья «Теория и методы промышленного управления»

    9. В. Баронов, И. Титовский, статья «Методы построения систем управления»

    10. В.П. Нестеров, И.Б. Нестеров, статья «Автоматизация деятельности организации»

    11. Мишель Селарье, Рой Харрис, статья «Извлечение дополнительной прибыли из производства»

    12. Броунин Фрайер, статья «Как посчитать норму возврата на инвестиции»

    13. Сар Эрмако Джонии, статья «Быть или не быть ERP?»

    14. С. Колесников, статья «Бизнес процесс реинжиниринг и внедрение автоматизированных систем управления»

    15. М. Ильина, статья «Принципы, средства и технологии реализации концепции управления»

    16. С. Колесников, статья «Об оценке эффективности внедрения и применения ERP систем»

    17. В.П. Нестеров, «Информационное обеспечение процесса принятия управленческих решений»

    18. С. Колесников, «Иерархия систем управленческого учета»

    19. И.И. Карпачев, «Классификация компьютерных систем управления предприятием»

    20. www.sap.com

    21. www.baan.com

    22. www.erp-people.com

    23. www.economics.ru