Некоторые типовые проблемы при эксплуатации АСОИУ

Эксплуатация АСОИУ начинается после того, как объект автоматизации полностью подготовлен, в частности:

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

Существует несколько традиционных принципиальных путей проектирования и разработки АСОИУ.

• 1. Создание АСОИУ по заказу (заказные системы). АСОИУ проектируются и разрабатывается по индивидуальному заказу предприятия или организации в специализированной ИТ-компании. Этот путь в современных условиях для разработки больших систем используется крайне редко. Тем не менее, такая разновидность АСОИУ, как сайт, напротив, очень популярна и ее разработка ориентирована именно на индивидуальный подход к каждому заказчику. Цель создания сайта, в первую очередь, состоит в том, чтобы на его страницах максимально возможно отразить конкурентные преимущества заказчика в отношении производимых им товаров или оказываемых услуг, и тем самым способствовать притоку клиентов.
• 2. Покупка готовых ППП определенного функционального назначения отечественных или зарубежных разработчиков. Одна из особенностей таких систем заключается в том, что все они включают в себя функциональность, которая полностью или частично может удовлетворить потребности автоматизированного решения большинства задач (поддерживающих соответствующие процессы или бизнес-процессы), возникающих в производственной и (или) управленческой сферах на многих предприятиях (организациях или других типах объектов автоматизации). Но поскольку при этом все готовые программные продукты изначально проектируются и разрабатываются не для реально существующего предприятия, то в качестве такового выступает некий «условный» объект автоматизации. Поэтому созданное в итоге программное приложение является в определенном смысле типовым в рамках какого-либо вида производственной или управленческой деятельности. Однако применительно к эксплуатации на реальном объекте автоматизации необходимо выполнить совокупность специальных настроек, качественный и количественный состав которых предусмотрен разработчиком.
• 3. Создание АСОИУ для конкретного объекта автоматизации, проектирование и разработка которой осуществляется силами специалистов, непосредственно работающих на таком объекте. Данный подход чаще всего практикуется для специализированных организаций, например, различных НИИ, ввиду специфических особенностей их предметных областей. Это обусловлено уникальностью проводимых исследований и спецификой используемой при этом информации.

Перечисленные пути проектирования и разработки не являются абсолютными и единственно возможными в их исходных ипостасях. Для реального предприятия (организации) могут быть задействованы особенности, характерные для каждого из путей. Например, часть функциональных модулей (отдельных задач или комплекса задач, сайты) разрабатываются по заказу, другая часть приобретается в виде готовых ППП, третья часть реализуется на внутрикорпоративном уровне. Возможны и другие сочетания. В частности, сайт создается силами ИТ-специалистов, которые работают на объекте автоматизации, вся остальная функциональность «закрывается» посредством закупленного ППП. Кроме того, для решения отдельных задач могут привлекаться даже фрилансеры. Несложно привести и другие, самые разнообразные варианты. Это зависит от различных факторов, например:

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

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

Любая АСОИУ выполняет две важнейшие функции: 1) одноразовая регистрация в системе информации обо всех совершенных атомарных операциях; 2) своевременное представление лицам, принимающим решения на всех уровнях управления, различных отчетов в необходимом и достаточном количестве, которые корректно отражают соответствующее положение дел за соответствующий период времени.

Рассмотрим несколько типовых проблем, с которыми наиболее часто приходится сталкиваться в процессе эксплуатации АСОИУ.

Проблема 1. Заключается в совершении ошибок при вводе первичной информации. Они возникают:

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

Для устранения или минимизации последствий данной проблемы могут быть предложены следующие решения:

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

Проблема 2. Один из принципов системного анализа, а именно,.

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

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

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

«Выравнивание» ситуации возможно только после переделки АСОИУ с учетом новых реалий, что займет определенное время. Таким образом, в процессе эксплуатации системы всегда существует некоторый временной лаг между фактическими изменениями на объекте автоматизации и изменениями в АСОИУ.

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

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

Мировой опыт показывает, что обновление версий АСОИУ осуществляется примерно раз в пять лет.

Проблема 3. Заключается в избыточности требований к функциональности АСОИУ со стороны конечных пользователей. Например, в системе программно предусмотрено формирование 100 форм отчетов и имеется запросная система, предоставляющая возможности для создания произвольных отчетов самими пользователями без обращения к услугам программистов. Но часто пользователи по разным причинам не хотят осваивать запросную систему и говорят, что АСОИУ «плохая», так как в ней отсутствует «101-ая» форма отчета. Решения для данной проблемы может быть два:

• 1) обучить пользователей работе по составлению необходимых им отчетов, которую они могут выполнять самостоятельно, т. е. «подавить» в них страх освоения новых технологий;
• 2) выяснить причины, которые привели к необходимости создания нового отчетного документа. Основных причин в принципе может быть три. Первая: некачественное проведение предпроектного обследования, в рамках которого были учтены не все потребности пользователей. Вторая: новая функциональность возникла вследствие какихлибо изменений на объекте автоматизации и в АСОИУ разработчики еще не успели их реализовать. Третья: не все ранее предусмотренные «100» отчетов по разным причинам нашли применение на практике, поэтому появилась необходимость заменить один или несколько из них на «101-ю» форму.

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

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

Проблема 5. Отсутствие вообще какой-либо проектной и эксплуатационной документации в тех случаях, когда проектирование, разработка и сопровождение АСОИУ осуществляется исключительно силами ИТ-специалистов, которые входят в состав персонала на объекте автоматизации. Это приводит к тому, что если кто-либо из специалистов не находится на своем рабочем месте (например, увольнение, длительная командировка, декретный отпуск, болезнь) возникает «пробел» на том участке в эксплуатации АСОИУ, за который он отвечал. Проблема усугубляется, если не предусмотрены «запасные варианты», т. е. другие сотрудники не знают особенности такого участка и к тому же не наделены необходимыми полномочиями для исправления возникших проблем.

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

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

Эксплуатация АСОИУ позволит, в частности:

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

Процесс эксплуатации АСОИУ необходимо обеспечить в организационном, информационном, техническом, и технологическом аспектах.