Андрей Орлов Записки автоматизатора Текст 2001 года. Книга, основой которой он послужил, вышла в издательстве МАНН, ИВАНОВ И ФЕРБЕР под названием "Записки автоматизатора. Профессиональная исповедь" и сейчас находится в продаже, например, на Озоне.

Сальдо мортале.
Каламбурчик

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

Теперь системы заказывают люди, которые тратят на них свои деньги (или почти свои, если речь идет о государственном или муниципальном заказе). И за свои деньги хотят что-то получить. Всегда ли они представляют, что именно, это отдельный вопрос.

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

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

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

Вас зовут на работу

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

А. Стадия первоначального накопления капитала

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

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

Осмысленность происходящего мало кого волнует: когда деньги сыплются, главным инструментом является не калькулятор, а лопата.

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

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

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

Б. Когда запахло жареным

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

Заветная надежда, связанная с автоматизацией в это время, была высказана в начале 80-х годов одним из заместителей министра путей сообщения в выступлении перед ИТР одного из министерских КБ: "Вы же все здесь очень талантливые люди. Ну сделайте такое электронное устройство, чтобы пропускная способность наших железных дорог увеличилась..." Талантливые люди очень вежливо посоветовали прокладывать дополнительные пути, чтобы было где ездить дополнительным поездам. С тех пор я успел поработать во многих местах, но смысл просьб руководства зачастую сводился к тому же. Наверное, все дело в том, что эти люди атеисты. Иначе бы они молили Бога. Хотя, по имеющейся у меня информации, Господь тоже редко помогает увеличивать прибыльность бизнеса без капитальных вложений.

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

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

В. Когда крах близок

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

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

И все информационные проекты замораживаются или сокращаются.

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

Что еще лучше понять сразу

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

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

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

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

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

Перед тем, как согласиться

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

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

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

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

Таблица

Чего не может понять большой начальник

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

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

Моральный кодекс наемного работника

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

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

Вы согласились

Итак, Вы все-таки согласились.

А. Осмотритесь

В первую же неделю работы необходимо составить и представить руководству документ, определяющий Ваши функции (функции руководимого Вами подразделения). Что-то типа "Основные функции и распорядок работы отдела ФИТ (фальсификационных и информационных технологий)".

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

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

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

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

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

Прежде всего, попробуйте составить для себя небольшой справочник "Who is who в фирме". Если Вам не удалось сделать это в течение первой недели работы, то прогноз печален.

Б. Разберитесь

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

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

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

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

Но как же часто после начальственных бесед и производственных совещаний я вспоминаю сцену из кинофильма "Бумбараш", в которой бандит, стреляя в направлении художника, кричит:

- Нарисуй мне кунгуру!

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

Теперь Вы поняли, что здесь я Вам не помощник. Дерзайте сами. Ведь именно Вы - "высококлассный профессионал-постановщик".

Но предположим, что Вы все-таки догадались, что Вам нужно сделать.

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

"Зачастую исполнительный директор страшно горд тем, что придумал велосипед с шестиугольными колесами вместо использовавшегося им ранее велосипеда с квадратными колесами. Он и не подозревает, что у нормальных людей колеса давно круглые." (Эту фразу я слышал несколько лет назад от А.В.Ширченко. К сожалению, я пытаюсь записать ее сейчас по памяти и сразу прошу прощения, если воспроизвел ее неточно).

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

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

В. Научитесь

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

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

Если не знаете, то Вам, наверно, рано писать задание для автоматизации учета в морге или крематории.

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

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

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

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

то Вы спроектировали систему плохо.

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

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

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

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

Г. И принимайтесь за работу

Теперь Вам придется определиться, воспользоваться ли покупной системой или программировать самим. И то, и другое имеет свои очевидные минусы: покупные системы никогда не заточены под Ваши задачи, а на собственную требуется такое количество ресурсов (и денег, и людей, нанимаемых не на постоянную работу, а "под задачу", что, бесспорно, ускоряет решение этой задачи, и, что самое главное, времени), которое в большинстве случаев недоступны.

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

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

Тут я Вам могу немного помочь.

Выбор системы

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

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

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

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

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

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

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

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

1. Уровень интеграции (склад, магазин, бухгалтерия, финансовая деятельность, логистика, есть ли учет услуг, договоров, включающих и товары и услуги, etc.), как связаны компоненты системы Насколько хлопотно получить бухгалтерские проводки по документу, как привязать товарный документ к конкретным оплатам, как оплатить расходную накладную частично кассовым ордером, а частично возвратной накладной, и можно ли это вообще сделать и т.д.
2. Идеология: от финансов, от документов, от товаров, etc. Разработчики обычно любят разглагольствовать на эту тему, однако смысл того, что они говорят, не всегда уловим. Иногда прояснить ситуацию позволяет простой вопрос: какой из модулей написан первым. Конечно, система "от склада" или "от бухгалтерии" звучит не так романтично и идеологично, зато дает определенное представление о том, как повернуты мозги разработчиков.
3. Поддержка разработчиком изменений в законодательстве.
4. Авторское сопровождение системы (нет, есть: бесплатно или платно). Его уровень (hot line, консультации у разработчика, консультации на месте, исправление обнаруженных ошибок, возможность модификаций, не связанных с ошибками, по запросу клиента).
5. Организация рабочего места (АРМ).

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

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

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

6. Возможность одновременного ведения реального и официального учета.
7. Возможности защиты, охраны и обороны данных. Авторизация воздействий на систему. Специальные вопросы: насколько быстро ваша система будет вскрыта УБЭП, существует ли возможность подключения процедур "отбеливания" информации, в том числе, в процессе штурма офиса "маски-шоу".
8. Работа корпорации (несколько юридических лиц и ЧП, ведение раздельного и консолидированного баланса).
9. Возможность ведения баланса партнера (контрагента).
10. Работа с контрагентом-корпорацией.
11. Возможность одновременного ведения реального и официального учета по контрагенту.
12. Работа с несколькими территориями (филиалами, складами, магазинами, партнерами (контрагентами)). Обмен данными: методы репликации, уровень обобщения; технические средства, возможные протоколы, интерфейсы и алгоритмы.
13. Ведение учета по партиям товаров, возможные варианты определения партии (товары данной поставки, товары данного поставщика, товары данного поставщика с одинаковой ценой поставки, товары данного поставщика за определенный период времени, etc.).
14. Подробность информации о контрагентах и производителях товаров.
15. Отслеживается ли товар в пути, деньги в пути.
16. Возможность вести учет в различных валютах, с несколькими обменными курсами, возможные моменты пересчета, ошибки округления и пересчета в документах и на карточках.
17. Различные упаковки и единицы измерения для одного товара (батоны, буханки и килограммы; бутылки и литры; далы (декалитры, приведенные к крепости напитков); возможности пересчета из одной единицы в другую; возможности добавления единиц измерения в процессе работы с товаром (хлеб захотели резать по полбуханки, жвачку продавать пластинками, а сигареты на штуки), получение данных и оформление документов в нужных единицах, ошибки округления. Характеристики габаритов, объема, веса.
18. Открытость системы

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

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

18.3. Возможность подключения 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. И, если честно, все это работает?

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

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

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

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

Вспомните MS Office. В документации ограничений объемов нет и в помине, Вы не получаете никаких сообщений и в процессе работы. Просто после пары преобразований листа Excel в 7000 строк, занявших у Вас 2 часа, Excel или система тихо зависнет.

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

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

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

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

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

Подбор персонала

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

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

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

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

Сейчас любая более или менее крупная организация уже имеет какие-то элементы автоматизированного учета (есть хотя бы компьютер, какая-нибудь бухгалтерская программа; если как-то автоматизирован складской учет, то обычно есть и локальная сеть). Персонал, который все это обслуживает, почему-то обычно называют мальчиками или программистами, хотя как правило эти люди программируют разве что bat-файлы. Американцы называют таких сотрудников IT-person, не отличая тех, кто больше нажимает на кнопки от тех, кто больше крутит отверткой. В последние годы и в российских IT-кругах для таких людей появилось новое название - "эникейщик". Квалификация этих специалистов слабо связана с зарплатой и варьируется от уровня advanced lamer до вполне серьезного.

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

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

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

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

Грустная шутка: "Компания "Супер-Софт" признала неисправимой в текущей версии своей системы очередную орфографическую ошибку".

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

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

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

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

Часть работ может быть возложена на внешних подрядчиков. Основным критерием для возможности передачи работ служит одновременное выполнение перечисленных ниже требований.

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

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

..........................................................................................................................................................

Стиль руководства

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

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

Сам я вряд ли могу научить, как надо руководить, зато точно могу сказать, как не надо.

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

Кроме того, вот несколько правил, которыми пользуюсь я.

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

Еще одно правило, специфическое для разработчиков программного обеспечения. Я им никогда не пользовался, хотя иногда и очень хотелось.

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

..........................................................................................................................................................

Формулировка задач (как получить то, что хочется)

В соответствии с российскими (и, кстати, американскими) стандартами составление технического задания (ТЗ) возлагается на разработчика. Это естественно, так как обычно клиент сам не знает, что хочет, что можно реализовать и как.

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

Посмотрим на примерах, к чему это приводит.

Пример. Невинная фраза из ТЗ:

"Все количество распределяется по всем покупателям поровну с округлением до 1 шт. Погрешность округления относится на последнего покупателя"

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

Итак, на 100 покупателей поступило 40 штук. Поровну означает 40/100 = 0,4 штуки. С округлением до одной штуки получается 0, то есть все 40 штук получит последний покупатель.

Еще веселее, если на 100 покупателей поступило 60 штук. Тогда все покупатели, кроме последнего, получат по одной штуке, а последний... -39 (минус тридцать девять) штук.

Программа соответствует ТЗ.

..........................................................................................................................................................

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

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

..........................................................................................................................................................

Очень жаль, что в техническом задании не принято писать "Программа должна работать."

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

.........................................................................................................................................................

Что такое "программа заработала". Когда начинать

Мы строили, строили, и, наконец...
Чебурашка

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

Однако по сей день однозначного ответа на вопрос, что же такое работающая программа, на мой взгляд, не получено, и вряд ли когда-нибудь будет получено. То, что во всех больших программах всегда содержатся ошибки, общеизвестно. Хотя неизвестно, что такое ошибка (этот вопрос долго и нудно приходится обсуждать с разработчиком при каждом составлении договора, а потом не менее долго и не менее нудно доказывать ему, что предъявленные результаты работы системы говорят об ошибке, и в тысячный раз выслушивать бред типа "Это не ошибка, раз Вы не можете ее повторить...").

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

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

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

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

Итак, равнение на Гейтса, и - вперед!

Ввод в эксплуатацию

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

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

До первой попытки я тоже считал, что это можно и нужно сделать. Но при внимательном изучении вопроса выясняется, что:

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

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

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

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

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

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

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

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

Учтите при этом, что скорость ввода информации при смене системы падает из-за изменения технологии, форматов данных и кодов и наименований.

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

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

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

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

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

К сожалению, кроме субъективных причин, типа "шилозадых" хозяев и начальников ("Я не могу ждать! Это приносит мне ежедневные убытки в пять тысяч долларов!" - про отказ срочно изменить способ сортировки товаров в отчете), существуют еще и объективные (введен или отменен очередной налог, Мосалкогольконтроль в пятый раз изменил форматы данных, которые ему нужно передавать еженедельно, сделалось 17 августа, и остатки склада в рублевых закупочных ценах превратились в полную абстракцию, не связанную с реальной жизнью, а формирование цен реализации как функции от закупочных стало верным способом разорения).

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

..........................................................................................................................................................

Кто виноват

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

• Поиски виновных.
• Наказание невиновных.
• Награждение непричастных.

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

Итак, не думайте, что вам за вашу работу ничего не будет. Будет и еще как.

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

- Программное обеспечение готово, чтобы вести разные цены?

- Ну, готово.

- Я говорил, что, по моему мнению, цены должны быть разными?

- Ну, говорил.

- Так в чем же я виноват?

- А почему ты нас не убедил, что это правильно?!!

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

..........................................................................................................................................................

Заключение

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

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

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

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

Это должно вернуть Вам утраченный оптимизм.

Так что успехов Вам.