ИС

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

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

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

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

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

81

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

Другим вариантом организационной структуры коллектива при создании крупных систем является иерархическая структура, базирующаяся на группах специалистов, каждая из которых составляет специализированную, так называемую «хирургическую бригаду», которую также часто называют «бригадой главного программиста», а подобный подход к формированию и функционированию коллектива – «метод главного программиста». Такая «бригада» решает достаточно автономную функциональную задачу и должна разработать и отладить группу взаимодействующих программ с достаточно четкой целью функционирования. «Бригада» рекомендуется в составе 7 – 10 специалистов с различными задачами и квалификацией. Схема информационных потоков между участниками такого коллектива изображена на рис.6.1.

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

82

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

Рисунок 6.1 – Схема информационных потоков между участниками коллектива

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

83

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

Одно из ключевых мест в подобном коллективе занимает главный постановщик. Главным постановщиком должен быть человек, хорошо разбирающийся в предметной области, для которой разрабатывается система. Его ошибки обходятся наиболее дорого. Согласно одному из законов Мерфи, «пользователь не знает, чего он хочет до тех пор, пока не получит в руки программный продукт». Как правило, вследствие этого систему придется переделывать, полностью или частично. Искусство главного постановщика – понимать, что нужно пользователю, лучше, чем сам пользователь. Именно от него зависит, сколько раз придется переделывать систему.

Рисунок 6.2 – Ошибки различных участников проекта по созданию информационной системы и их влияние на выполнение отдельных стадий проекта и проекта в целом

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

84

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

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

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

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

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

7. Проблемы внедрения информационных систем

Несмотря на то, что вопросы предпроектного обследования и ввода в

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

85

отечественного, так и зарубежного производства. Рассматриваемые ниже вопросы касаются некоторых проблем внедрения этих систем на отечественных индустриальных предприятиях. Речь идет о системах класса ERP/MRP II – R/3 (SAP AG) , MK/X (Computer Associates), Triton (BAAN), BPCS (SSA), CIIM (Avalon), ORACLE Applications (ORACLE), MFG/PRO (QAD), «Галактика» «IT-Предприятие» и т.д., т.е. о многофункциональных системах для финансово-экономического сопровождения различных типов управленческих и производственных процессов. Все перечисленные системы имеют примерно одинаковый набор более или менее удачно реализованных функциональных модулей для таких сфер, как финансы, снабжение и сбыт, обслуживание оборудования и реализованной продукции. Эти функциональные модули и системы в целом и будут рассматриваться в дальнейшем как объекты внедрения.

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

7.1. Внедрение как технология

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

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

86

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

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

Сдача в опытную эксплуатацию

Сдача в промышленную эксплуатацию

Рисунок 7.1 – Карта внедрения

1)подготовка персонала;

2)подготовка технического обеспечения;

3)подготовка программного обеспечения (общесистемного и прикладного, т.е. работа с самой внедряемой системой и ее отдельными модулями);

4)работа с уже имеющимся прикладным программным обеспечением (на карте внедрения эта линия обозначена как «Подготовка старого программного обеспечения»).

87

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

Перед тем, как произойдет «разделение» процесса внедрения на указанные линии, предприятие должно пройти обследование. Задача такого обследования – понять, возможно ли внедрение вообще. И если ответ положительный, то результатом этого этапа работы должно стать составление карты внедрения. Линии процесса внедрения, изображенные на карте вертикальными столбцами, не изолированы друг от друга: они находятся под единым управлением и между ними возможна передача информации и ресурсов (горизонтальные связи на рис.7.1)

7.2. Классификация внедренческих проблем

Поскольку успех внедрения – событие случайное, то попробуем сформулировать его вероятность как функцию от следующих «аргументов»:

1)понимание внедряющей фирмой бизнес-процессов на предприятии;

2)знание внедряющей фирмой теории и практики учетной и плановой деятельности;

3)наличие на предприятии «оппозиции» (работников, которые сопротивляются внедрению системы) и умение находить с ее представителями общий язык;

4)умение вовремя распознать симптомы, которые делают невозможным внедрение информационной системы на данном предприятии;

5)технологичность внедрения (ее уровень повышается от внедрения

квнедрению).

Попытаемся классифицировать симптомы «невнедряемости». Можно выделить три источника проблем внедрения информационных систем: сама система, предприятие и внедряющая фирма. Теперь рассмотрим каждый источник подробнее:

1. Проблемы, типичные для информационных систем:

88

1) несоответствие местным (украинским, российским) принципам бухгалтерского учета и планирования;

2)неразвитость средств настройки и доработки;

3)отсутствие версий для популярных на местном рынке платформ (например, хорошая в принципе система BPCS реализована только для платформы AS/400);

4)высокие требования к вычислительным ресурсам (на фоне удешевления аппаратных средств эта проблема постепенно теряет свою остроту для всех систем, кроме, может быть, R/3).

2. Проблемы, типичные для внедряющих фирм:

1)непонимание внедренцами бизнес-процессов на предприятии и, как следствие, недостаточная детальность предпроектного обследования;

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

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

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

5)опора не на тех людей на предприятии (существует опасность спутать истинных сторонников внедрения системы с примкнувшими к ним исходя из конъюктурных соображений);

6)поверхностное знание методики обследования и, как результат, – профанация самой процедуры обследования;

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

3. Проблемы, типичные для предприятий:

1)враждебное или безразличное отношение рядовых сотрудников к внедряемой информационной системе и к самим внедренцам;

89

2) наличие на предприятии собственных программных наработок для ЕС ЭВМ или персональных компьютеров (на FoxPro, Clipper и т.д.) и желание их использовать;

3)отсутствие локальной сети в требуемой конфигурации;

4)использование процесса внедрения в «подковерной» внутризаводской борьбе (если процесс внедрения идет удачно, необходимо вовремя присоединиться к внедренцам, если нет – быть в первых рядах критиков).

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

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

Самостоятельное внедрение

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

90