сначала читать руководителю информационной службы, а затем — обсуждать с директором предприятия.
Это третья часть статьи, адресованной руководителям небольших динамичных предприятий, для которых грамотное внедрение информационно-управляющей системы (ИУС) стало важным для выживания. Примером могут служить предприятия розничной торговли, проще — магазины, хотя те же проблемы есть и в других отраслях.
|
Системотехнические требования
Работы по оценке системотехнических требований приложения, возникающие проблемы и способы их решения хорошо известны техническим специалистам, это — их поле деятельности. Здесь мы ограничимся всего лишь несколькими соображениями, которые важны для правильной организации работ по выбору приложения, а также теми, которые имеют отношение к текущей ситуации.
Требования к общесистемному обеспечению
Возможно, для выбора приложения при сравнительно одинаковых функциональных характеристиках решающим может оказаться размер затрат на необходимое общесистемное обеспечение, или «платформы», к которым мы относим: компьютеры, операционные системы, системы управления базами данных, сетевое оборудование и т. д. Оценивая варианты выбора, важно определять не только первоначальные затраты, но и затраты при возможном расширении и развитии системы, а также расходы по поддержке общесистемного обеспечения.
Полезно учитывать тот факт, что поставщики приложений часто имеют «вкусовые» предпочтения и что независимая экспертиза полезна для того, чтобы оценить варианты с точки зрения самых разных статей затрат и видов риска (зарплата и расходные материалы, смена версий и необходимость переустановки программ и др.). Учтите, что срок морального старения компьютеров гораздо меньше, чем приложения, если оно имеет достаточную адаптивность. Поэтому бессмысленно выбирать приложение под «перспективные» версии платформ, которые все равно многократно устареют за время службы приложения, если, конечно, оно верно выбрано. Надежность и открытость приложения — вот главные системотехнические критерии.
Открытость
Комплексные приложения, как правило, имеют долгий срок жизни. Чрезвычайно важно все это время иметь возможность расширять функциональный состав ИУС за счет стыковки с другими системами или комбинирования приложения с новыми компонентами, но такое расширение возможно только при условии открытости интерфейсов выбираемого приложения. Разработчик должен четко и ясно описать внутреннее взаимодействие программных единиц между собой и с базой данных.
Не стоит рассчитывать на то, что разработчик будет сам делать для вас все работы по развитию вашей системы, в большинстве случаев это нереально. Имеется в виду не характеристика надежности фирмы-разработчика. Например, дело не в том, что небольшая отечественная фирма может быть якобы не такой надежной, как очень большая зарубежная — здесь как раз возможны самые разные ситуации. Дело в том, что привязавшись к одному разработчику, вы рискуете оказаться заложником его планов развития следующих версий приложения (какие функции и как он будет развивать, какие выбирать платформы и тому подобное), вы можете зависеть от очередности обслуживания вас его специалистами, от цен на его услуги, даже от его отношений с другим поставщиком, приложение которого позже вы захотите включить в свою систему.
Открытость — это не только свойство переносимых платформ или приложений между платформами. Может быть, именно в годы бурных перемен становится особенно важной открытость приложений и информационно-управляющих систем на уровне компонентов приложений, сделанных разными разработчиками. Чем проще интерфейсы между компонентами, чем ими легче пользоваться при развитии системы, чем полнее они описаны — тем лучше. Итак: проверяйте открытость интерфейсов компонентов приложения при его выборе, проверяйте также открытость разработчика на полноту описания внутреннего устройства приложения.
Сертификация компонентов
Ваше приложение в итоге должно будет взаимодействовать с конкретными СУБД и операционной системой, а те — на компьютерах конкретных марок. И все эти компоненты системы должны надежно работать друг с другом. В значительной степени надежность функционирования системы определяется положительными результатами тестирования ее компонентов, проведенного фирмами-производителями тех платформ, на которых должны работать эти компоненты.
Например, приложение, которое вы оцениваете, имеет архитектуру клиент-сервер и использует Windows 95 и Unix соответственно. Вы должны учитывать, что практически все компьютеры имеют сертификацию для работы с Windows 95, но далеко не все компьютеры, претендующие на роль серверов, корректно работают с операционной системой Unix. Поэтому при подборе компонентов надо внимательно относиться к сертификатам соответствия, которые даются фирмами-производителями.
Особое значение эти эффекты могут приобрести в ближайшее время, если часть зарубежных поставщиков будет потеснена отечественными сборщиками Intel-машин. Само по себе это может быть и неплохо, но контроль за совместимостью компонентов всей информационной системы скорее всего станет более трудным.
Эксплуатационные свойства
Контроль и управление доступом
Диалоговая многопользовательская работа ИУС требует жестких ограничений на доступ к функциям системы и к данным в ней, а также контроля за работой пользователей. Ограничения доступа к данным включаются в приложения чаще, во многом они могут поддерживаться механизмами СУБД, но и тут есть простор для проблем и проверок способов их решения в приложении. А вот проверка наличия, полноты и качества средств контроля за работой пользователей требует особого внимания. Так, каждый документ должен иметь идентификатор автора и идентификатор группы пользователей. Это, с одной стороны, позволяет вести в системе персонифицированный учет обработки документов, с другой — дает возможность организовать коллективную работу с нужными ограничениями. Пользователь может работать только со строго определенными функциями и документами, все остальные функции и документы должны быть для него недоступны.
Чрезвычайно важны средства контроля системы в аспекте работ пользователей. Например, системный журнал прикладного уровня должен содержать полную фиксацию всех действий каждого пользователя и времени их совершения. Такой журнал позволяет получить статистику работы системы, причем не как совокупности ее «технических» частей, а как ИУС, состоящей из работников предприятия и функций приложения. Данные этого журнала позволяют проводить оценку эффективности работы пользователей и оптимизировать технологию их работы.
Надежность и живучесть
Система должна обеспечивать высокую надежность функционирования. Надежность системы с рассматриваемой точки зрения определяется двумя основными факторами: надежностью технического обеспечения и надежностью программного обеспечения. Надежность технического обеспечения указывается в характеристиках, даваемых фирмами-производителями. Сложнее оценивать надежность программного обеспечения. Определенную оценку можно получить путем тестирования. Это в первую очередь касается функциональной надежности. Никакие действия пользователя в рамках предоставляемого приложением интерфейса не должны приводить к разрушению данных и отказу в работе системы.
Планируя тесты, нужно предусмотреть проверки того, как будут обрабатываться аварийные ситуации: отключение питания, выход из строя аппаратных компонентов и т. д. При выборе приложения чрезвычайно важно оценить живучесть системы, то есть ее способность продолжить функционирование — пусть даже с худшими характеристиками — при выходе из строя отдельных компонентов.
Средства архивации и восстановления должны предоставляться также для обеспечения нескольких уровней надежности и живучести системы. Так, в ней должна существовать возможность создания архивов как всей прикладной системы, так и личных архивов пользователей.
Надежность партнерства
Компетентность
Несмотря на все требования к открытости и самой прикладной системы, и ее разработчика, необходимо осознавать, что вы выбираете не столько приложение, сколько партнера в долгой и трудной работе по совершенствованию управления предприятием. Поэтому так важно увериться в том, что организация, с которой вы начинаете столь значительную работу, способна ее осуществить. Необходимо достаточно близко познакомиться с коллективом исполнителей, их методами работы, уровнем компетентности, опытом работы.Поскольку в этом и следующем году ожидаются или уже проходят крупные реорганизации многих фирм — разработчиков приложений и фирм-консультантов, можно посоветовать обращать внимания не только — или не столько — на имя фирмы, но, в первую очередь, на реальную компетентность ее сотрудников.
Уровень услуг
Вот несколько важных аспектов в части услуг, которые нужны от партнера.
Во-первых, это наличие методики и технологии внедрения приложения на объекте. Известно, что наиболее трудоемким является именно этап запуска системы, который связан с большим объемом аналитической и тяжелой ручной работы по созданию нормативно-справочной информации, а также с настройкой параметров различного назначения. Как правило, при запуске системы требуется большая работа по первичному вводу данных. При этом происходит множество не всегда комфортных и часто — всего лишь первых контактов специалистов организации, внедряющей систему, персонала, которому предстоит эксплуатировать эту систему, и людей из подразделений, втянутых в процесс внедрения и использования приложения. Для преодоления возникающих здесь проблем очень важно иметь четкую методику и технологию внедрения. Конечно же, одного этого мало, заказчики должны полностью осознать важность и трудоемкость этого этапа и оказывать всяческое содействие разработчикам.
Во-вторых, это уровень и качество поддержки приложения в процессе эксплуатации. Неизбежно при этом будут выявляться ошибки проектирования, неудобства работы, новые требования на расширение состава функций или на их модификацию. Необходимо выяснить, как эти проблемы будут решаться разработчиками по срокам и по затратам.
В-третьих, это полнота комплекса услуг, который может быть оказан организацией, внедряющей приложение. Может ли она обеспечить поддержку всех работ и компонентов: ремонт техники, прокладку и монтаж сети, обновление общесистемного обеспечения и т. д.
Перспектива развития
Приобретая приложение, пользователь должен представлять перспективы развития и приложения, и самой организации разработчика, так как, возможно, на долгие годы планы их работ в области информатизации будут тесно связаны. В нормальной ситуации должны быть четко обозначены основные направления и этапы развития приложения, а также основные направления и планы работ организации-разработчика.
К сожалению, в реальной жизни почти всегда и почти все разработчики программного обеспечения, начиная с больших зарубежных фирм, нарушают свои внутренние плановые сроки. Но этот «феномен» легко отличить от отсутствия у разработчиков продуманных и обоснованных планов.
Важно и другое. Если планы у разработчиков существуют, но не совпадают с вашими устремлениями, вы можете заранее больше внимания уделить использованию возможностей компонентной открытости приложения.
Очень коротко о самом важном
Можно так подытожить сказанное в трех частях этой статьи:
- Прежде чем приступать к информатизации, поймите и сформулируйте главное: что вы хотите получить в конечном итоге и какими шагами вы будете двигаться к конечной цели? Сэкономив на этом, вы можете понести невосполнимые потери в дальнейшем. Оптимальным является привлечение независимых консультантов для проведения обследования и формулирования целей и задач.
- Тщательно оцените функциональность анализируемого приложения. Вы должны убедиться, что приложение достаточно качественно решает ваши задачи. Подготовьте примерную технологическую схему работы с приложением. Опытным путем проверьте технологичность работы. Привлеките опытных сотрудников, которые должны проиграть на системе наиболее каверзные ситуации, а также проверьте скорость работы приложения в типовых и в наиболее сложных ситуациях.
- Оцените все затраты на приобретение, внедрение и эксплуатацию системы. В этих оценках просматривайте не только текущую ситуацию, но и перспективное развитие. Обязательно проанализируйте аварийные и критические ситуации. Не ориентируйтесь на компьютерную «моду», помните: срок жизни приложения намного больше, чем срок жизни любой платформы. Мало того, как показывает практика, ценность приложения со временем увеличивается, так как уменьшается число ошибок, проходит полная адаптация к конкретному объекту. Особо обратите внимание на возможности настройки приложения на изменения внешней среды (законодательства, налогов, состояния рынка), а также на изменения внутренней структуры объекта.
- Помните: вы выбираете не только приложение, но и партнера по управлению вашим предприятием. Это особенно остро почувствуют те предприятия, которые не имеют своих подразделений для развития и модификации приложения.
Евгений Константинович Ким — директор Центра исследований и проектирования ООО СЕПТ. С ним можно связаться по адресу sept@monk.lz.space.ru.