Выбор приложения для управления предприятием

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

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

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

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

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

Что такое "функциональная полнота"

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

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

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

Для проведения таких экспертиз на основе программы информатизации нужно сформировать объединенный перечень требований к составу функций приложения. Детальность описания требований будет определять возможную детальность экспертиз. Вот пример достаточно редкого, но вполне реального требования: фиксировать партии товара, описанные совокупностью разных единиц измерения по образцу "два ящика по 20 кг нетто, три упаковки по 10 пачек, 250 г нетто каждая, и 20 пачек по 100 г нетто". Если требование определено так детально, то и экспертиза функций приложения может планироваться так же конкретно и детально. В перечне требований должна сохраняться их разбивка на стадии реализации программы. Это позволит по-разному подходить к возможным несоответствиям функций приложения, например требованиям к обязательному ядру или требованиям "периферийного" слоя.

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

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

Сотрудники и консультанты

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

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

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

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

Функциональная производительность и ресурсоемкость

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

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

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

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

Адаптивность к эволюции целей

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

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

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

Технологическая полнота

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

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

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

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

Адаптивность к изменениям технологии

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

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

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

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

Эргономичность и возможности адаптации

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

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

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

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

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

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