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

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

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

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

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

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

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

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

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

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

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

В итоге можно рассчитывать на следующие выгоды.

1. Повышение качества собственно материально-технического снабжения:

· сотрудникам ОМТС не составит труда работа с поставщиками, когда под рукой информация о возможностях и расценках различных поставщиков, о потребностях производства и их обеспеченности на настоящий момент;

· сотрудникам ОМТС будет легче работать с внутренними подразделениями предприятия, ориентируясь на заявки и отслеживая степень их выполнения, а также отклонения от норм расходов ресурсов;

· сотрудникам ОМТС будет проще ориентироваться при отпуске ресурса на сторону, зная о наличии излишков и их стоимости.

Здесь речь идет о повышении обоснованности решений, принимаемых в ОМТС.

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

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

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

5. Повышение интеллектуальности труда (уменьшение объемов рутинных операций и новый уровень информированности) и облегчение поиска новых решений по улучшению организации службы МТС и др.

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

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

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

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

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

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

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

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

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

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

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

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

Программный комплекс “Снабжение”

Итак, клиент не только принципиально готов к компьютеризации своей службы снабжения, но и определил для себя, что именно он хотел бы получить. НИИ "Центрпрограммсистем" и его фирмы-сателлиты (“Тверские компьютерные системы” и “RGD-Тверь”) предлагают потенциальному заказчику комплекс программ "Снабжение" как вариант решения проблемы.

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

· директора по МТС (начальника отдела МТС);

· экономиста (инженера) отдела МТС;

· работника склада;

· администратора базы данных и системы.

Все составляющие комплекса выдержаны в единой идеологии, имеют стандартные интерфейсы, опираются на идентичную структуру данных и максимально учитывают специфику работы конечных пользователей. Система решена так, что в зависимости от объемов информации и величины предприятия возможна работа всех АРМ как на одном компьютере, так и в локальной сети. Пожалуй, наиболее приемлемым по критерию стоимости внедрения вариантом установки компонентов комплекса для крупных заказчиков является следующий (рис.1): АРМ АБД, директора и несколько АРМов работников ОМТС базируются на компьютерах, объединенных в локальную сеть; АРМы работников склада устанавливаются на автономных машинах; компьютеры на складах и компьютер АБД снабжены модемами и имеют выход на телефонные линии (с целью обмена информацией между складами и БД ОМТС, поддерживаемой в локальной сети).

Локальная сеть

                                     Директор МТС

                                                                    Телефнная

О М Т С                                                связь

                                           А Б Д                                                                           Склады

 Рис.1

Основные функции ОМТС, реализованные в рамках АС "Снабжение"

1) Работа с подразделениями:

сбор заявок подразделений и составление сводных заявок в различных разрезах; выдача разрешений на отпуск материалов подразделениям завода; анализ обеспеченности подразделений; анализ отклонений от норм расходов и др.

2) Работа с клиентами:

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

3) Работа со складами:

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

4) Работа с поставщиками:

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

5) Работа с бухгалтерией:

учет оплаты счетов по договорам и взаимозачетов и др.

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

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

Функции АБД и системы следует обсуждать отдельно, поскольку на больших объемах информации и при значительном количестве пользователей системы работа АБД становится не тривиальной. АБД снабжается инструментами, предназначенными для выполнения процедур от копирования и восстановления данных и информационного обмена "склады – база данных ОМТС" до анализа своей работы с помощью специальной функции-контролера, фиксирующей действия администратора.

Прикладные программы написаны на базе СУБД Paradox для DOS 4.0 (русифицированная версия), что позволяет создавать изящные и понимаемые другими программистами программы, без особого труда вносить серьезные изменения и включать незапланированные функции. В связи с тем, что в качестве администратора системы нередко выступают люди, не имеющие специальной подготовки, выбор СУБД существенно влияет на жизнеспособность системы. Комплекс снабжен подробной документацией, описывающей структуру базы данных, реализуемые функции, ограничения целостности данных, порядок и процедуры обмена информацией с удаленными складами и многое другое.

При работе с заказчиком реализуются следующие принципы.

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

· Передача системы заказчику с подробным ее описанием и с исходными текстами программ.

· Формирование у заказчика с первых этапов разработки группы АБД (для поддержки процессов внедрения и функционирования системы).

· Авторский надзор в течение года.

АБД и целостность БД

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

Обязанности обслуживающего персонала программного комплекса (в частности АС "Снабжение") достаточно сложны и разнообразны. Будем рассматривать их только с точки зрения обеспечения нормальной работы БД.

Не лишено смысла суждение, что все проблемы баз данных связаны с поддержанием их целостности. Фундамент целостности БД закладывается в процессе разработки ее структуры, когда нормализация является необходимым условием исключения аномалий добавления, модификации и удаления данных. Следующий этап (тоже необходимое, но не достаточное условие) – это правильное использование связей между файлами (таблицами, кортежами и т.д., в зависимости от терминологии, наиболее близкой проектировщику системы) и разумная последовательность обработки данных. Иными словами, второе необходимое условие обеспечения целостности данных – это учет данного требования в программах. При этом определенные возможности предоставляет системное программное обеспечение (например, автоблокировка записей в основной и подчиненной таблицах при совместном редактировании в сети в среде Paradox), а часть обязанностей ложится на разработчика (от контроля ввода путем проверки форматов и использования таблиц поиска до разработки корректных процедур по обмену данными между автономными фрагментами БД (на складах) и базой данных ОМТС).

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

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

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

Для этого обратимся к примеру. Структура фрагмента базы данных (с сокращениями) приведена на рисунке 2.

Еще раз отметим, что данная схема сильно упрощена (например, из пяти ключевых полей в основной части накладной на схеме указано только одно (отмечено "*")), но для понимания сути дела этого вполне достаточно.

Выделим связи, которые будет проверять АБД после разного рода сбоев и ошибок.

· Связи между файлами нормативно-справочной информации (НСИ – НСИ), например связь по значению поля "Наименование группы" в файлах "Группа ресурсов" и "Ресурс". АБД вынужден выявлять ситуации: ресурс, для которого нет соответствующей группы в справочнике групп; группа, не включающая ресурсов; ресурс, принадлежащий одновременно двум группам (наличие вместо связи 1:М связи М:N).

· Связи между файлами нормативно-справочной и оперативной информации (НСИ – ОИ), например связь по значению поля "Наименование клиента" между справочником клиентов, с одной стороны, и основной частью накладной в текущей и архивной БД – с другой.

 Текущая БД Архивная БД

 Основная часть Основная часть

 накладной Клиент накладной

 № накладной * М:1 Наименование 1:М № накладной *

 клиента *

 Наименование Наименование

 клиента Адрес клиента

 Посредник Банк Посредник

 . . . . . . . . .

 1:М

 Содержание Содержание

 накладной Группа ресурса накладной

 М:1  № накладной * Наименование № накладной *

 группы *

 Наименование Наименование

 группы * Характеристика 1:М группы *

 Наименование . . . Наименование

 ресурса * ресурса *

 . . . 1:М . . .

 Количество Ресурс Количество

 разрешенное разрешенное

 Наименование

 Количество группы * 1:М Количество

 выданное выданное

 Наименование

 . . . ресурса * . . .

 Характеристика

 . . .

Рис. 2

· Связи между файлами оперативной информации (ОИ – ОИ), например связь по значению поля "№ накладной" в основной части накладной и содержании накладной для текущей БД.

· Возможен контроль оперативной информации не только на наличие, но и на отсутствие связей (ОИ/ОИ). Если по условиям функционирования БД не должно быть ситуации, когда переведенная в архив накладная остается и в текущей БД, то АБД обязан выявить пересечение данных.

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

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

Для иллюстрации обратимся к такому примеру.

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

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

Внедрение системы

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

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

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

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

Вывод из сказанного прост: предпроектное обследование – не способ разработчика выбить из заказчика сумму , а гарантия от "сюрпризов" при внедрении системы.

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

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

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

Нередко заказчик задается вопросом: а нельзя ли провести внедрение большой системы силами, например, одного, но очень квалифицированного специалиста? Строго говоря, внедрение крупного программного комплекса – это в лучшем случае 10 % творчества, а остальные 90 % – рутина. Здесь и мелкие корректировки в исходных текстах, и изменение документации, и установка программ на многих рабочих местах, и проблемы с техникой, обучением персонала, и многое другое. И если мы говорим о крупном предприятии, то все это умножается на объем обрабатываемой информации и количество объединяемых комплексом людей. Если же речь идет о предприятии, где эксплуатировать систему будут 2-3 человека, то, естественно, сложность такого внедрения невелика.

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

Целью настоящей статьи не являлась ни разработка научной концепции построения комплекса программ для снабжения, ни четкая систематизация проблем внедрения подобной системы. Просто автору хотелось, с одной стороны, помочь потенциальному заказчику сделать первый шаг в выборе действительно подходящего ему программного продукта (не обязательно “Снабжение”), с другой стороны, хотя бы отчасти подготовить клиента к тем проблемам, которые предстоит решить при внедрении системы совместными усилиями заказчика и разработчика. Понимание проблем, совместные усилия и общая ответственность заказчика и разработчика – необходимые условия внедрения сложной системы. И достаточные.