Записки автоматизатора. Профессиональная исповедь - Андрей Орлов

Тем более удивляет огромное количество публикаций консалтинговых компаний, проводящих сравнение программ по их функциям. Читая такие обзоры, часто понимаешь, что сделаны они именно по названиям функций. На такие рейтинги и обзоры часто любят ссылаться продавцы систем («Наша система набрала 99 очков из 100 по шкале компании Ы» или «По оценке экспертов N наша система является лидером в области Э»). Встречаются даже совсем курьезные тексты – например, описания того, что «система N повышает удовлетворенность пользователей на 30 %», или попытки сравнивать программы на основании получаемого разработчиком дохода от продаж. – Д. К.

Тем не менее некоторые характеристики, очевидно, служат для отбора систем до их подробного изучения. К таковым относятся:

– максимальное количество рабочих мест, на которое рассчитана система;

– оценочная стоимость и продолжительность внедрения;

– место разработки системы: зарубежная или отечественная;

– возможность дорабатывать систему под нужды клиента (открытость системы).

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

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

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

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

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

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

Только поймите, это не те сумма и время, которые потратите вы. Эта те сумма и время, меньше которых вы не потратите точно.

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

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

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

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

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

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

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

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

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

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

– большинство этих специалистов работает вовсе не над теми проблемами, которые стоят перед вами;

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

– огромное количество этих человеко-лет потрачено на функциональность, которая никогда на данном конкретном предприятии использоваться не будет;

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

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

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

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