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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы понять некоторые неудобства от работы с такой системой, вспомните свой опыт работы с MS Word, который всегда лучше вас знает, как форматировать текст, нумеровать и оформлять списки, учит вас, что в русском языке прилагательные c приставкой «не» всегда пишутся отдельно, и предлагает исправить выражение «номинировать на конкурс» на правильное: «но минировать на конкурс». Если вас это все не бесит, вы, может быть, и с иностранной системой уживетесь.

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

– А больше можно? Ведь нам даже в официальном учете их необходимо сделать пять.

– Можно, если скриптик написать.

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

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

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

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

Кстати, о логотипе. Не забывайте сами и не уставайте напоминать руководству, что корпорации Microsoft Inc. не разрабатывала систем Navision и Axapta[1]

Она купила фирму Navision вместе с ее программными продуктами,[2] поэтому ждать от этих продуктов исключительной совместимости с продуктами Microsoft не нужно. Равно как не нужно надеяться, что при разработке этих продуктов использовались соответствующие технологические стандарты корпорации Microsoft. Компания SAP пошла еще дальше: она купила продукт, который сейчас продает под названием SAP Business One, у израильских разработчиков, не купив при этом самих израильских разработчиков, так что самостоятельно не может даже исправить ошибки в этом продукте. Настоящие «Жигули» с официально установленной трехлучевой звездой от «Мерседеса».

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

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

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

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

Как истинный ретроград, я предпочитаю смотреть на модель «сущность−связь» (ER-модель), но годится и любая другая общеизвестная модель, лишь бы она была описана в литературе, а не придумана самими разработчиками.

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

Многие западные системы поставляются с «готовой» методологией внедрения (фактически это перечень шагов развертывания системы в идеальном мире, некий «сферический конь в вакууме»). Частью таковой обычно является и типовой план, выглядящий примерно так:

1. Продажа лицензий и установка системы (конечно же, самый главный и своевременный этап);

2. Обучение;

3. Концептуальное понимание;

4. Функциональное описание;

5. Разработка;

6. Внедрение;

7. До свидания.

Конечно же, хорошо, что типовой план существует, но про время на настройку восьмидесяти видов рабочих мест я бы уточнил дополнительно…

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

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

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