Участники построения КИС, их мотивации и модели взаимодействия.

Субъекты процесса создания и эксплуатации корпоративной информационной системы (КИС):

Университет, как целое

  • структурные подразделения университета;
  • ППС;
  • сотрудники;
  • студенты;
  • ДИТ;
  • УИТО;
  • неформальные группы и отдельные специалисты.

Крупные вендоры и поставщики IT-решений масштаба предприятия

  • 1С;
  • SAP;
  • Oracle.

Поставщики программных продуктов для локальных задач

  • Программа печати дипломов;
  • Марк;
  • и др.

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

  • Библиотека
  • система для ПЭУ на Oracle
  • и др.

Поставщики OpenSource-решений отдельных компонент

  • Moodle;
  • Drupal;
  • Django;
  • Postgres;
  • и др.

Разработчики работающие в университете

  • Деканат;
  • Электронный журнал;
  • Канцелярия;
  • Система заказа пропусков;
  • Система для интеграции любых информационных систем (база обмена данными - БОД);
  • и др.

КИС, в разной степени, затронет всех учащихся и работающих в университете, а также привлекаемых внешних акторов (субъектов).

Мотивация субъектов

   Субъекты

    Мотивация

Университет, как целое

  • Удержание лидерства, усиление бренда

  • Повышение качества выпускаемого продукта

  • Расширение доли рынка

  • Увеличение прибыли

  • абитуриенты, студенты, другие учащиеся

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

  • факультеты, кафедры, ППС, сотрудники

Ломка с таким трудом налаженных процессов, годами устоявшихся процедур?
НИКОГДА!!!

  • ДИТ, УИТО

Вся тяжесть координации разработки и эксплуатации ляжет на них - они потребуют штатов и бюджетов. Если не получат - будут саботировать.

  • программисты университета

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

  • неформальные группы и отдельные люди

  • энтузиасты, искренне и бескорыстно желающие помочь - их будет мало;

  • профессионалы, предполагающие поучаствовать, заработать и вписать строку в свое портфолио;

  • жулики - постараются урвать, отмыть, откатить от жирного бюджета.

Крупные вендоры и поставщики IT-решений масштаба предприятия

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

Поставщики программных продуктов для локальных задач

Продать копию своего продукта и забыть. 

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

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

Поставщики OpenSource-решений отдельных компонент

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

 

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

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

Всем участникам (т.е. всему университету) необходимо понять:

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

Сценарий 1

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

 

Сценарий 2

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

 

Сценарий 3

Унификация стыковых компонент и Единая интеграционная платформа позволят складывать пазл информационных систем без разрывов и самоделок. Возможно это только на основе кооперации с другими университетами - так уже давно делают в США (альянс частников), подобное есть в Европе и Китае (под эгидой государства). Это самый правильный путь - при минимальных издержках каждого участника - все пользуются очень качественными продуктами, легко интегрируемыми между собой.

 

 

Все иллюстрации и исходники здесь.