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

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

Результатом этой ситуации становится то, что некоторые на полном серьезе даже предлагают считать нормальным «совместное использование зарубежной системы класса 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. И, если честно, все это работает?

* * *

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