KnigaRead.com/
KnigaRead.com » Компьютеры и Интернет » Прочая околокомпьтерная литература » Андрей Орлов - Записки автоматизатора. Профессиональная исповедь

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

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн "Андрей Орлов - Записки автоматизатора. Профессиональная исповедь". Жанр: Прочая околокомпьтерная литература издательство неизвестно, год неизвестен.
Перейти на страницу:

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

Пример из той же 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.).

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*