Разработка и внедрение единой информационной системы управления отраслевым учебным заведением

Вид материала

Документы

Содержание Сервер приложений Серверы приложений Служба каталогов Клиентские приложения Службы дорог

Подобный материал:

• Техническое задание на выполнение работы «Создание информационной системы автоматизации, 387.86kb.
• Типовой план проекта «Разработка стратегии и внедрение системы стратегического управления», 117.19kb.
• Управления, 53.19kb.
• Курсовой работы должна соответствовать сельскохозяйственной, промышленной или образовательной, 28.04kb.
• Разработка и внедрение технологии промышленного производства и системы управления качеством, 660.17kb.
• Концепция создания единой государственной информационной системы в сфере здравоохранения, 359.32kb.
• Концепция создания единой государственной информационной системы в сфере здравоохранения, 359.22kb.
• Конкурс 3 раздел приглашение к участию в конкурсе, 5218.55kb.
• Тихона Задонского является православным общеобразовательным учебным заведением, 44.27kb.
• Алексеева является полнопрофильным учебным заведением современного типа, 72.74kb.

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


В. И. Колесников, д.т.н. чл.-корр. РАН, ректор РГУПС

Ростовский Государственный Университет Путей Сообщения

В. Д. Верескун, к.т.н. доцент, проректор РГУПС по экономике, инвестициям и информатизации

Ростовский Государственный Университет Путей Сообщения

Н. Н. Сухорукова нач. упр. информатизации РГУПС

Ростовский Государственный Университет Путей Сообщения


Аннотация

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


Переход на рыночные отношения, изменение экономических и социальных условий внесли существенные изменения во все бизнес-процессы учебных заведений отрасли, что, в свою очередь, повлекло за собой необходимость внесения изменений в функционирующее в учебных заведениях программное обеспечение, используемое для информационной поддержки основного и вспомогательных бизнес-процессов. В июне 2000 года в РГУПС состоялось совещание проректоров по информатизации вузов отрасли. В ходе совещания выяснилось, что практически ни в одном вузе отрасли нет информационной системы, охватывающей всю совокупность бизнес-процессов. Каждый вуз ведет разработку информационных подсистем, автоматизирующих некоторые части основного бизнес-процесса – бизнес процесса обучения. Эти подсистемы представляют собой АРМы сотрудников различных подразделений вузов, как правило, связанных между собой на уровне традиционного бумажного документооборота. Причем даже в рамках одного вуза может существовать несколько платформ. Большинство бухгалтерских подсистем являются приобретенными, что еще больше затрудняет их интеграцию в единую систему. Совещание проректоров пришло к выводу, что наиболее целесообразно общими усилиями разработать единую для всех учебных заведений отрасли автоматизированную систему управления, тем более что во всех вузах имеются высоко квалифицированные кадры в области информатизации. Была выбрана единая платформа – СУБД ORACLE. На этом же совещании было отмечено, что РГУПС имеет большой опыт разработки и внедрения АСУ, все подсистемы АСУ, функционирующие в РГУПС, являются собственными разработками. Была начата разработка единой для всех учебных заведений отрасли системы управления. Основным разработчиком системы является РГУПС.

Проведена следующая работа:

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

На сайте РГУПС есть специальный раздел ORAFORUM, где РГУПС выставляет все разработанные документы, структуры базы данных, описание интерфейсов и процедур.

В феврале 2002 года в РГУПС был проведен семинар – совещание представителей вузов МПС, в котором приняли участие 9 вузов МПС. Участники выработали единые требования к подсистемам, планируемым к разработке в первую очередь. Определен перечень и очередность разработки подсистем. В первую очередь должны быть разработаны и внедрены базовые подсистемы, содержимое баз данных которых используется остальными подсистемами. Это “Ведение нормативно – справочной информации” (административная структура учебного заведения, роли и привилегии, план счетов, различные нормативы, почтовые адреса, должности, профессии и т.д.), “Кадры сотрудников”, “Контингент студентов”, “Учебные планы”, “Рабочие планы”, “Фонд помещений”. На сегодняшний день эти подсистемы разработаны и внедрены в постоянную эксплуатацию в РГУПС. Разработана структура базы данных, структура хранилищ информации для учебного заведения и для Департамента кадров МПС. Разработаны и внедрены в эксплуатацию в РГУПС и 4-х филиалах РГУПС еще 7 подсистем. Это “Оплата за обучение”, “Учет договоров на оплату за обучение”, “Ведение расчетного счета”, “Распределение нагрузки на кафедры”, “Распределение нагрузки на преподавателей”, “Тестирование”, “Контроль исполнения смет подразделений”. Внедряется в эксплуатацию 2 подсистемы в СамГАПС – “Контингент студентов” и “Приемная комиссия”. Разработана и внедрена технология ведения хранилищ агрегированной информации.

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

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

Разработка и внедрение Системы должна обеспечить решение следующих задач:

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

Система в целом должна иметь следующие свойства:

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

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

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

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

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

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

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

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

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

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

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

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

Выделим группы:

Серверы приложений – непосредственно несущие нагрузку по проведению бизнес-транзакций.

Менеджмент серверы – обеспечивающие процесс управления комплексом в целом.

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

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

Клиентские приложения:

• ЦКАДР – предоставляют доступ к агрегированной информации учебных заведений системы МПС в разрезе учебного заведения, так и по всем учебным заведениям. Доступ к информации осуществляется посредством WEB технологий.
  
• Службы дорог – предоставляют сведения по целевикам, имеющих направление от дороги. Доступ к данной информации осуществляется также посредством WEB технологий.
  
• Учебных заведений – осуществляют электронный документооборот. Выделяется внутренний документооборот, отчетность и межвузовский обмен.
  
• Филиалов – предоставляют механизм отчетности филиала перед базовым Вузом. Сведения по приемной комиссии, итоги учебной и хозяйственной деятельности передаются через сеть Интернет.
  

Структура разрабатываемого программного обеспечения (ПО) включает следующие группы:

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

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


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

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

Принята следующая схема актуализации информации: в филиалах и учебных заведениях ведется оперативная обработка информации, ведутся основные базы данных. Ввод информации осуществляют работники административных и учебных подразделений (бухгалтеры, работники деканатов, сотрудники УМУ и УК, ПФУ и т.д.). В каждом учебном заведении постоянно обновляется хранилище агрегированной информации этого учебного заведения. Аналитические системы уровня учебного заведения работают в основном с данными хранилища. Это значительно ускоряет процесс обработки данных, так как процедуру обновления хранилища можно запускать в часы наименьшей нагрузки на сеть, например, ночью. Каждая аналитическая программа должна иметь 2 режима работы – с хранилищем и с основной базой, что дает возможность мониторинга процессов. Информация из отдельных хранилищ собирается в общем хранилище, с которым работают аналитические системы верхнего уровня, которые должны иметь 3 режима: с верхним хранилищем, хранилищем учебного заведения и с основными базами.


Таким образом руководство учебного заведения, работники аппарата ЦКАДР МПС могут получать различные сводные ведомости и отчеты ежедневно, актуальность их может быть или за прошедшие сутки, или на текущий момент времени. Все эти процедуры разработаны с использованием INTERNET- технологий. Деятельность учебного заведения обеспечивается ресурсами, нормативными документами и управленческим аппаратом, использующим АСУ.

Можно условно разделить АСУ учебного заведения на следующие группы: «Ректорат», «Бухгалтерия», «Приемная комиссия», «Управление кадрами», «Планово – финансовое управление», «Учебно – методическое управление», «Деканаты», «Кафедры», «Административно – хозяйственная работа».

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

Взаимосвязь этих групп подсистем и данных можно показать на примере уже работающей АСУ РГУПС.

Созданные и внедренные подсистемы решают следующие задачи:

Группа подсистем «Контингент студентов»:

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

Группа подсистем «Планово – финансовое управление»:

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

Группа подсистем «Бухгалтерия»:

• кассовый учет;
  
• ведение расчетного счета
  

Группа подсистем «Административно – хозяйственное управление»:

• учет и контроль за принадлежностью, использованием и состоянием аудиторного, лабораторного, административного и др. фондов помещений РГУ ПС;
  

Группа подсистем «Учебно-методическое управление»:

• учет целевых и персональных договоров и формирование отчетной документации для руководства РГУ ПС, МПС и СКЖД;
  
• формирование нерегламентированных запросов.
  

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

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

Группа подсистем «Приемная комиссия»:

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

• формирование отчетной документации для руководства РГУ ПС, МПС и СКЖД.
  

Группа подсистем «Деканаты»:

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

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

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

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

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

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

Задача реинжиниринга (речь идет преимущественно о программном обеспечении) является сложным многоступенчатым процессом.

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

Степень и характер реорганизационной деятельности – предмет рассмотрения индивидуальной ситуации. Логично предположить (и практика подтверждает это (5)), что на этапе проектирования АСУ необходимо учитывать, например, особенности традиционного документооборота предприятия. Однако ставить учет этого фактора во главу угла и пытаться сохранить все как было противоречит базовым принципам реинжиниринга. Фактически, в этом случае мы имеем дело с автоматизацией офиса, темой важной, но связанной с реорганизационной деятельностью косвенно. Кстати, впервые термин "реинжиниринг бизнес-процессов" (от англ. business process reengineering, BPR) был введен Майклом Хаммером в 1990г. в статье “Реинжиниринг: не автоматизируйте – уничтожайте” (6). Он, в частности, пишет: «Серьезные инвестиции в информационные технологии принесли разочаровывающие результаты во многом из-за того, что компании применяют технологию, чтобы механизировать старые способы ведения дел». Реинжиниринг программно-аппаратного обеспечения, как составная часть реинжиниринга бизнес-процессов предприятия, своей целью имеет оптимизацию производственного и логистического процессов, ликвидацию противоречий в организационной структуре, сокращение времени исполнения бизнес-процессов на всех этапах. Проведение реинжиниринга целесообразно в ходе комплексной оптимизации организационной схемы и упорядочивания информационных потоков, особенно в случае территориально распределенных структур. Наверное, самым ярким представителем таких структур является МПС России. АСУ-ВУЗ РГУПС разработана с учетом возможности функционирования в условиях территориальной распределенности.

При внедрении системы в РГУПС мы столкнулись с обычными для такого процесса проблемами.

1. Потенциальные пользователи привыкли к сложившейся ситуации, когда обмен информацией между подразделениями идет на уровне бумажных документов, которые получаются или с использованием офисных программ, или локальных АРМов. При такой технологии не обязательна автоматизация всех рабочих мест и операций. Как показала практика, примерно 60% работников на таких рабочих местах психологически не готово к работе на компьютере.
   
2. Если же работник использует офисные программы, то возникает чувство протеста против того, что сотрудники, ранее использовавшие исходящие от него бумажные документы, могут пользоваться информацией уже в готовом, электронном виде. Например, приказы, выпускаемые отделом кадров об изменении оклада работнику, уже не требуют повторного ввода в подсистему расчета зарплаты, и работник отдела кадров считает, что он выполняет работу бухгалтера – расчетчика, хотя объем и характер выполняемой кадровиком работы и не изменился.
   
3. Еще одна проблема – это непонимание исполнителями того, что документ, созданный подсистемой АСУ, и документ, созданный офисной программой – разные по сути документы, хотя они и имеют одинаковый вид, и абитуриент, зачисленный по приказу, сформированному в WORD, не появится как студент в базе данных контингента соответствующего деканата.
   
4. Кадровая проблема. Для внедрения и сопровождения всего комплекса подсистем, в том числе и ведения НСИ, требуется 2 сменных администратора СУБД ORACLE и 3 программиста сопровождения. Без администраторов СУБД систему внедрить гораздо сложнее, в таком случае программистам придется выполнять функции администратора. При условии, что предполагается внедрение ПО без каких-либо изменений, а сопровождать будет РГУПС, можно обойтись без программистов.
   

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

Одно из положений разработанной концепции – информация должна вводиться в базу данных там, где она возникает, и выбираться из базы конечным пользователем. Это значит, что на ВЦ (в отделах АСУ) учебных заведений ликвидируются отделы или группы эксплуатации, специалисты ВЦ отвечают только за сохранность информации и корректность работы программного обеспечения. Актуальность информации должна поддерживаться соответствующими подразделениями. В должностные обязанности практически всех сотрудников административного аппарата должен быть внесен пункт, обязывающий работать на компьютере с соответствующим АРМом.


Наиболее распространенные в литературе рекомендации по технологии внедрения информационных систем (ИТ):

1. Должна быть организована рабочая группа для внедрения
   
2. Руководитель группы должен быть специалистом в области информационных технологий или иметь о них понятие
   
3. Сотрудники группы должны иметь соответствующую квалификацию, обязанности сотрудников должны быть документально определены
   
4. Руководитель группы должен быть достаточно авторитетным в организации человеком. В западных компаниях это часто второе лицо в компании
   
5. Руководитель группы должен хорошо разбираться в деятельности предприятия, организации производства
   
6. Каждый этап внедрения должен подкрепляться руководящими документами (приказами)
   
7. Рекомендуется на время внедрения забыть о таких понятиях как “реинжиниринг” и “сокращение”, иначе сопротивление персонала будет непреодолимо. Рекомендуется изменения в существующих бизнес – процессах проводить постепенно, не связывая их с процессом внедрения.
   

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

Цитата из книги Билла Гейтса «Бизнес со скоростью мысли»:

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


Список литературы:

1. BYTE/Россия, №11, 1999 Проблемы обучения информационным технологиям, проф. А.Н.Терехов, зав. кафедрой системного программирования СПбГУ и др.
   
2. lting.ru/ Устранение препятствий для успеха реинжиниринга. Вольф Шумахер, DBA
   
3. lting.ru/ Управление проектами при создании информационных систем С.Колесников
   
4. kov.ru/ Руководителю предприятия. Внедрение системы автоматизации, основные проблемы и задачи.
   
5. ru/ Автоматизация хаоса, или Записки консультанта
   
6. Hammer M. "Reengineering Work: Don't Automate, Obliterate". Harvard Business Review, July - August 1990.
   
7. Oracle 8 Уроки программирования. Баженова И.Ю., "Диалог-МИФИ" – 2000
   
8. Корпоративные системы на основе CORBA. Дирк Слама, Джексон Гарбмс, Перри Рассел. Издательский дом "Вильямс" – 2001
   
9. hat.ru/ Трехзвенная архитектура корпоративной информационной системы. А. Шутов