• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

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

Такие уже есть. – Д. К.

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

Ангажированность авторов, изучающих и обозревающих эти вопросы, зачастую видна уже на уровне определений и классификации. Очень много сил отдано проработке определения КИС – корпоративной информационной системы, ИУС – информационно-управляющей системы, ИСУП – интегрированной системы управления предприятием, системы класса ERP – Enterprise Resource Planning, ERPII, стандарта MRPII – Manufacturing Resource Planning. После того как определение тем или иным способом сформулировано, обычно делается вывод, что информационная система, продвигаемая авторами публикации, определению соответствует, в отличие от систем-конкурентов.

Да, это все равно что говорить, что продукт соответствует стандарту ISO 9000 (видел я и такое). – Д. К.

При этом ERP-стандарта попросту не существует, а MRPII американской ассоциации управления производственными ресурсами APICS – это концепция управления производством и запасами, то есть методология менеджмента, а не стандарт информационной системы.

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

Тем более удивляет огромное количество публикаций консалтинговых компаний, проводящих сравнение программ по их функциям. Читая такие обзоры, часто понимаешь, что сделаны они именно по названиям функций. На такие рейтинги и обзоры часто любят ссылаться продавцы систем («Наша система набрала 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. До свидания.

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

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

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

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

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

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

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

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

И вроде должно быть понятно: когда что-то работает так, что ни в сказке сказать, ни пером описать, это что-то надо переделать. Но объяснить это руководителю проекта, истекающему слюной по бонусу за закрытие этапа, удается чрезвычайно редко.

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

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

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

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

Если не очень понятно про штрихкоды.

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

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

Однажды я даже получил официальное письмо на бланке с подписью и печатью, текст которого достоин опубликования:

«Доводим до вашего сведения, что с 01.01.2001 модуль Бухгалтерия называется Главная книга».

Без комментариев.

Ниже приводятся варианты толкования разработчиком некоторых терминов.

Логистика. Читаем в словаре: «Логистика – теория и практика управления материальными и информационными потоками в процессе товародвижения». Как дисциплина логистика занимается вопросами оптимизации при оформлении, перемещении и хранении товаров. В большинстве же систем модуль «Логистика» раньше назывался «Склад». Он считает складские остатки и ничего не оптимизирует. Но вам может встретиться и система, в которой модуль «Логистика» занимается учетом перевозок. И тоже ничего не оптимизирует.

Контрагент – лицо или учреждение, берущее на себя известные обязательства по договору. Это по словарю. Но в зависимости от системы справочником контрагентов будет называться либо справочник организаций, либо справочник (набор справочников), который используется в бухгалтерских и/или складских карточках и включающий как организации, так и физические лица, подразделения, темы и даже товары. Когда я попытался не так давно сам описать проект тиражируемой информационной системы, я обнаружил, что очень тяжело подобрать общее название для всех объектов и субъектов, фигурирующих, например, в договоре, накладной, платежном поручении (отправители, получатели, плательщики и т. п.) и в разрезе которых ведется материальный и аналитический бухгалтерский учет. Я бы назвал такие объекты фигурантами, но понимаю, что систему, где используется такая терминология, никто в России не купит.

Что интересно, в отечественных системах часто один справочник – «контрагенты», а в большинстве зарубежных – и «поставщики», и «подрядчики, и „перевозчики“, и т. п. Как следствие, ответ на вопрос „«кто сколько нам должен?“«получается не совсем очевидным… – Д. К.

Бухгалтерский учет—термин используется как для метода учета, описанного еще Пачоли и использующего двойную запись, так и для части учета, предназначенной для демонстрации налоговой службе, в противоположность управленческому учету. Как разработчики используют последний термин, тоже нужно разбирать особо. Во всяком случае фраза «Управленческий учет построен по принципам бухгалтерского учета» оказалась для некоторых разработчиков не такой ясной, какой представлялось мне.

А вот это исключительно наше изобретение. Во всех остальных странах управленческий учет – это не «черная касса», а просто более детализированный учет (в основном учет затрат и доходов). Управленческий учет в западном его понимании совсем не противоречит финансовому. – Д. К.

Кроме отдельных понятий оказывается смазанным также и смысл целых предложений. Высказывание «В системе поддерживаются стандарты бухгалтерского учета РСУ, IAS, GAAP» может означать:

1) что учет возможно организовать по любому из стандартов, но ровно по одному;

2) что, используя счета и проводки, сделанные по российским правилам, можно сваять отчет по IAS или какому-нибудь из GAAP;

3) что для одного из GAAP или для IAS используются свои счета и свои типовые хозяйственные операции.

Нет такого стандарта, как GAAP. То есть совсем нет. Многие страны именуют свои правила учета «общепринятыми» (то есть generally accepted, или GAAP), поэтому аббревиатура бессмысленна без указания страны, откуда родом стандарт (например, US GAAP). – Д. К.

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

Пример из той же Axapta. В свое время термин invoice разработчик перевел (что характерно для западных систем) как «счет-фактура». Беда заключалась в том, что в те времена в законодательстве не существовало определенного срока, в течение которого нужно было выдавать эту фактуру, и были возможны ситуации, когда ее либо не существовало вовсе, либо она выдавалась со значительными задержками сразу на много поставок. В результате – либо в системе не следовало формировать фактуру до момента ее поступления (результатом чего становилась неучтенная задолженность), либо формировать (и получить косяк с формированием отчетности по НДС, в которой операция не считалась таковой без нужных бумажек). – Д. К.

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

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

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

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

Но если вы услышите фразу: «Мы как раз сейчас разрабатываем версию системы, которая в точности удовлетворяет вашим потребностям», – улыбнитесь как можно лучезарнее и скажите: «Замечательно! Дайте мне знать, когда эта версия будет готова», – и бегите, бегите из того места, где вам это сказали!

Итак, вопросы.

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

2. Идеология: от финансов, от документов, от товаров etc. (Разработчики обычно любят разглагольствовать на эту тему, однако смысл того, что они говорят, не всегда уловим. Иногда прояснить ситуацию позволяет простой вопрос: какой из модулей написан первым. Конечно, система «от склада» или «от бухгалтерии» звучит не так романтично и идеологично, зато дает определенное представление о том, как повернуты мозги разработчиков. Отрадно отметить, что сейчас на рынке появились системы, которые продумывались при проектировании целиком.)

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

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

3. Поддержка разработчиком изменений в законодательстве. (Не стесняйтесь спрашивать: «Что произойдет, когда Госкомстат заменит форму ТОРГ12 на ТОРГ13?» – в ответ иногда можно услышать и правду: «Сами исправите или нам денег заплатите».)

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

4. Авторское сопровождение системы (нет, есть: бесплатно или платно). Его уровень (hot line, консультации у разработчика, консультации на месте, исправление обнаруженных ошибок, возможность модификаций, не связанных с ошибками, по запросу клиента)

5. Организация рабочего места (АРМ).

5.1. Набор функций жестко задан разработчиком (например, «АРМ бухгалтера/АРМ кладовщика/АРМ менеджера по продажам», причем эти АРМы организованы так, что менеджер по продажам не может посмотреть остатки склада) или произвольно конфигурируются администратором системы.

5.2. Варианты организации доступа к данным:

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

– как выделяется: полный доступ/только чтение;

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

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

7. Возможности защиты, охраны и обороны данных. Авторизация воздействий на систему. Специальные вопросы: насколько быстро ваша система будет вскрыта УБЭП; существует ли возможность подключения процедур «отбеливания» информации, в том числе в процессе штурма офиса «масками-шоу».

8. Работа корпорации (несколько юридических лиц и ПБОЮЛ, ведение раздельного и консолидированного баланса).

9. Возможность ведения баланса партнера (контрагента).

10. Работа с контрагентом-корпорацией.

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

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

Угу. Распределенка и что с ней будет, если грохнется канал. – Д. К.

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

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

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

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

17. Различные упаковки и единицы измерения для одного товара (батоны, буханки и килограммы; бутылки и литры; далы (декалитры, приведенные к крепости напитков)). Возможности пересчета из одной единицы в другую (саморезы покупают килограммами, а продают штуками). Возможности добавления единиц измерения в процессе работы с товаром (хлеб захотели резать по полбуханки, жвачку продавать пластинками, а сигареты на штуки), получение данных и оформление документов в нужных единицах, ошибки округления при переводе из одной единицы в другую. Можно ли задать точность единицы измерения? (Был случай, когда у меня на складе осталось 0,1 бутылки коньяка.) Характеристики габаритов, объема, веса.

18. Открытость системы.

18.1. Возможность экспорта и импорта данных (текстовые файлы, MS Office, различные СУБД, бухгалтерские системы, программы «Клиент?банк», выдача информации в необходимых форматах для налоговой службы, пенсионного фонда, Госкомстата, службы занятости, служб алкогольконтроля etc.).

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

18.3. Возможность подключения OLAP-продуктов или встроенный OLAP. Если разработчик уверен, что у него «встроенный OLAP», то опять-таки придется разобраться, что он имеет в виду. Предполагаю, что вы такого и предположить не могли.

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

А также исходные тексты чего и на каких условиях передаются. Например, я встречал продукты, где лицензировалось количество создаваемых программистом объектов. – Д. К.

19. Сетевые операционные системы, СУБД, операционные системы рабочих мест, метод работы с сервером (клиент-сервер, файл-сервер или их гибриды).

20. Ограничения по объемам баз данных и классификаторов, характеристики производительности

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

21. Необходимые и допустимые технические средства. (Технические характеристики и возможные типы компьютеров, электронных весов, сканеров и принтеров штрихкодов, кассовых аппаратов, устройств работы с пластиковыми картами etc.).

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

23. Способы калькуляции себестоимости, средневзвешенных цен, методики списания (по средневзвешенной, FIFO, LIFO, срок годности, минимальная/максимальная цена закупки etc.). Для корпоративных систем: возможность различной настройки для разных компаний корпорации.

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

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

26. Возможность контроля плановых запасов.

27. Автоматический учет пеней и штрафов (факт, прогноз и анализ).

28. Учет работы и оплаты менеджеров, торговых агентов, коммивояжеров и др.

29. Слияние/разделение товаров (один товар зарегистрирован в системе с разными кодами, разные товары попали в систему под одним кодом).

30. Слияние/разделение контрагентов (ИНН попадает в систему позже ввода в систему контрагента).

31. Наличие утилит для обрезания и сжатия разбухшей базы данных.

32. Наличие интегрированных в систему средств архивирования данных.

33. И, если честно, все это работает?

Итак, вы получили ответы на свои вопросы. Что дальше?

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

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

– не поддерживают объемы данных, как минимум в десять раз превосходящие объемы, заложенные в проект;

– не поддерживают одновременную работу числа пользователей, превышающего проектное в два-три раза;

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

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

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

Но не стоит путать удобный интерфейс и графический а-ля Windows – в упомянутом выше случае работа мышкой не всегда лучший вариант. – Д. К.

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

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

Экстраполяции временных характеристик вам не помогут: они могут изменяться нелинейно. И если даже сохранение документа в десять тысяч товарных позиций происходит в сто раз медленнее, чем у документа в сто товарных позиций, то скроллинг строк этого «монстра» может происходить и в десять тысяч раз медленнее.

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

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

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

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

Выбор системы руководством, конечно же, не спасет вас в случае неудачи от виселицы. Но вы пойдете на нее с чистой совестью.

Правда, руководство само тоже не всегда склонно принимать решение и произносит сакраментальную фразу: «Давайте проведем тендер».

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

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

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

Как третий вариант, можно привлечь стороннюю компанию («консультант по работе с консультантами»), которая проводит обследование и составляет описание требований. Однако при этом желательно, чтобы такая компания участвовала во внедрении и дальше, беря на себя часть работы по постановке задачи и контролю ее реализации.

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

И даже привлечение стороннего консультанта не спасает от того, что написано выше: решение будет принимать руководство компании. – Д. К.

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

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

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

Если же по материалам, присланным на тендер, решение принимаете вы и ваше руководство, то… я это уже описал в предыдущих главах.