Есть много материалов о том, как внедрение 1С помогло компаниям избавиться от потерь, сократить затраты, вырубить на корню воровство. Это прекрасно, когда получается избавляться от зла в таком большом объеме.
Моя статья — про зло помельче. Про саботаж внедрений, про вечное "я все правильно делаю, это ваша программа виновата", про раздутие штата, про мелкие корпоративные интрижки и сопротивление переменам.
Все в статье — из личного опыта, с примерами использования. На уникальность и полное раскрытие темы не претендую, высшей истины здесь нет, обобщений старался избежать, ничего не навязываю.
Просто опыт применения некоторых инструментов и примеры того, как они меня выручали.
Запись действий пользователей с временнЫми параметрами в 1С
Честно не помню, зачем я эту штуку сделал, но пригодилась она несколько раз. Разработка простая и топорная, занимает не больше часа. Не везде применима, т.к. может отъедать много ресурсов и данные занимают много места на диске, поэтому за ней нужно следить.
Принцип простой:
- записывает, когда пользователь открыл форму (документа, справочника, отчет, обработку);
- записывает, когда он ее закрыл;
- записывает, когда он ее записал (если это сохраняемый объект, вроде документа или справочника);
- записывает, был ли это новый объект, или старый;
- записывает все, что надо знать об объекте — ссылку, имя типа, имя пользователя, имя формы.
В итоге имеем большую таблицу с данными, и несколько вычисляемых цифр. Например, знаем "средний чек" — сколько времени уходит на создание приходной накладной у бухгалтера. Знаем, сколько раз бухгалтер возвращается к ранее созданному документу, чтобы его изменить, и сколько тратит на это времени.
Приведу примеры, когда механизм пригодился.
Первый — устранение мелкого саботажа внедрения. Внедрялся механизм комплектации заказа на складе — кладовщик должен был отмечать собранные в ящик позиции. Кладовщикам было четко сказано — без фанатизма, работайте с системой только когда будет время свободное.
Через день прибегает менеджер по отгрузке, говорит — кладовщики отказываются грузить машину, говорят, что им надо вбивать данные в какую-то систему и у них на это уходит 2 часа в день. Разумеется, быстро объясняю, что никто им таких распоряжений не давал. Открываю свой отчет, вижу — тратят в день 20 минут на всех. Сказал менеджеру, сказал кладовщикам — все, больше таких заявлений от них не было.
Второй пример. Финдир заказывает некий функционал для управления деньгами. Что важно — не потому, что хочет, а потому, что этого контура учета не хватает вышестоящим. Потом на общем совещании его спрашивают — ну чего, когда данные появятся. Он говорит — там ошибки, не работает, мы программистам задание на доработку напишем. Открываю отчет, показываю — ни он, ни его девочки ни разу не заходили ни в документ, ни в отчет. Все, внедрение двинулось дальше.
Третий пример. Бухгалтерия говорит — нам надо расширить штат, у нас вырос документооборот. Руководство, памятуя о моем отчете, спрашивают — дай статистику, что там у них выросло.
Первый же подсчет в лоб — количество документов и количество строк в них — показал, что документооборот не вырос.
Ладно, думаю, может там что-то усложнилось в документах, реально может труднее стало их оформлять.
Смотрю "средний чек" и его динамику по двум бухгалтерам — нет, вроде не растет, не падает.
Тут дошло — недавно ушел старый бухгалтер, на его место взяли двух новых. Данные у меня были по всем трем, сравниваю — ба, вот оно. Два новых бухгалтера вводят документы медленнее, чем один старый.
Все, расширение штата отменилось, надо просто подождать, пока набьют руку. Заодно — немножно автоматизировать.
Из третьего примера следует четвертый, уже позитивный. Видя динамику "среднего чека" по типам документов, мы стали ее использовать для анализа автоматизированности операций и последствий вносимых изменений. Если "средний чек" подрастал, то анализировали причины, наблюдали за людьми вживую и улучшали.
Запись значений показателей
Технически это одно из решений кастомизации на лету. Суть простая — пишется схема компоновки, которая вычисляет какую-то цифру и сохраняет ее в системе с нужной периодичностью. В итоге имеем динамику по времени для цифры.
Многие цифры запоминать не нужно, т.к. они воспроизводимы. Например, нет нужды запоминать объем продаж — его всегда можно посмотреть ретроспективно.
Но некоторые цифры можно воспроизвести только подняв бэкап базы. Например, только так можно узнать, сколько у вас было отрицательных остатков на счете 10.01 месяц назад. Кто читал предыдущие мои статьи, понимает, что речь об Айсберге.
Первый пример использования. Есть проблемы с зачетом аванса — достаточно большая сумма висит одновременно на 60.01 и 60.02. Функционал типовой, методических трудностей нет — просто укажи правильную аналитику в документах, и аванс зачтется. На совещаниях бухгалтерия говорит — нет проблем, сделаем. На каждом следующем совещании повторяет — делаем, там много работы, автоматизировано плохо. На меня смотрят косо.
Прихожу, включаю запись показателя — суммы незачтенного аванса. Думаю — нет, отмажутся, скажут что незачтенный аванс растет быстрее, чем они его исправляют. Делю показатель на три части — сумма на начало года, сумма на начало месяца, сумма на сегодня.
На следующем совещании показываю цифры — как было и как стало. Незачтенный аванс на начало года и начало месяца стоит колом — ничего не исправляли. Незачтенный аванс на сегодня почти не изменился — значит, сейчас документы нормально оформляют. В итоге старые ошибки исправили за 2 дня.
Второй пример использования. Автоматизировали снабженцев, функция простая — программа говорит, сколько чего надо заказать у поставщиков, бери и заказывай. Отдельно, указанный механизм пишет уровень текущий дефицитов. Смотрим — по одним позициям дефицит уменьшается, по другим растет. За позиции отвечают разные люди. На совещании все говорят — да да, все делаем как велено, смотрим, заказываем. Почему дефициты растут — не знаем, наверное автоматизация плохая, цифры неверно посчитаны. Все косо смотрят на меня.
Иду в лоб — смотрю оформленные заказы поставщикам. Сходу разобраться не удается, т.к. документы вводятся и изменяются неоперативно — это нормально, т.к. процесс согласования заказа может занимать несколько дней, и он все это время корректируется.
Ставлю запись двух показателей индивидуально по каждому снабженцу — сколько каких позиций было к заказу на утро, сколько из них заказал в течение дня. И вуаля — "хороший" менеджер (аккуратная девочка) заказывал 85-100 % того, что требовала система, "плохие" — 15 %. Все, пошла работа с дисциплиной. Что интересно — снабженцы, увидев этот отчет, попросили дать его им в использование (сами снабженцы, а не их руководитель). Разница между моим и их отчетом была простой. Их отчет показывал текущие остатки, а мой еще показывал "время жизни" этих остатков.
Фиксация идей
Несколько раз слышал от программистов, что у них воруют идеи, особенно их начальники. Слушают идею, говорят что она ниочем, а через какое-то время выдают за свою.
У меня идей обычно много возникает, про качество судить не буду, но по факту их много. Я несколько лет назад заметил, что я их не запоминаю. Бывает, что придумываю идею по несколько раз.
Потом увидел на сайте студии Артемия Лебедева, что они записывают идеи, и считают это полезным. Решил поступить также — в системе учета задач (наподобие 1С:Документооборот) сделал себе раздельчик, куда стал эти идеи записывать. Он был доступен только под полными правами, т.к. нужен был только мне.
Потом в компании решили систематизировать работу с рационализаторскими предложениями — подачу, оценку, учет реализации и т.д. Меня спросили, можно ли автоматизировать, я сказал — уже все автоматизировано, показал свой механизм. Немного доработал, чтобы было голосование, комментарии, учет реализации, постановка задач и т.д. Но суть не в этом.
Суть в том, что идеи стали публичными и зафиксированными, и украсть их стало сложно. Мои — почти невозможно, т.к. на момент открытия системы для пользователей там уже содержалось несколько сотен моих записей.
Первый пример использования даже не требовал моего участия. Идеи читали многие, и когда кто-то где-то высказывал предложение, читатели ему открыто говорили — а, была такая идея, посмотри в системе, там и обсуждение есть. Если я не присутствовал в этом разговоре, то выдумщика присылали ко мне, и обычно он начинал фразу с "ты вот идею такую предлагал, я почитал, она интересная, давай реализуем…".
Второй пример связан с продвижением системы рационализаторских предложений. К функционалу фиксации идей я, естественно, прицепил отслеживание прочтения. И получалось так, что сотрудники некоторых отделов, реально стремившиеся изменить свою работу к лучшему, начали вносить свои предложения в систему. Но реализовывались только предложения, связанные с автоматизацией, т.к. мне это было интересно.
На совещаниях руководителям задавался вопрос — как у вас с реализацией предложений? Есть полезные идеи от ваших сотрудников? Многие дружно отвечали — не, ничего интересного, ерунда всякая. Показываю отчет — в систему вообще не заходили, ни одной идеи не прочитали, не говоря уж о реализации. На всякий случай переспросили у сотрудников — может вы устно или по почте свои предложения даете руководителям? Нет, говорят, отродясь такого не было, и вообще боимся голову поднять.
Данные предоставили, процесс сдвинулся с мертвой точки.
Фиксация данных
Это относительно новый механизм, тоже по принципам кастомизации на лету, воспроизводится за несколько часов.
Его цель — расширить возможности версионирования. Обычно версионирование (как типовое, так и не типовое) фиксирует изменения первичных данных — справочников, документов и т.д. В реальной практике этого бывает недостаточно.
Например, "слетела оборотка" с разными вариациями "слетания". Традиционный путь — либо смотреть изменения документов, которые могли повлиять, либо поднимать бэкап, выгружать детализацию в эксель и сравнивать обороты.
Проблема еще в том, что момент "слетания оборотки" должен отслеживать человек.
В итоге сделал несложный механизм, который красиво хранит свернутую структуру оборотов и реагирует на изменения. И область данных, которую фиксировать, и свертка, и периодичность — настраивается через СКД.
Если будет интересно, воспроизведу и выложу.
Не вдаваясь в детали, механизм сигнализировал об изменениях области данных ("слетела оборотка") в течение часа (это периодичность срабатывания регл.задания), указывал область данных, указывал период, и давал возможность найти первичные данные.
Да, и позволял "принять изменения" — если все было честно, то измененные данные становились эталонными, и слежка шла уже за изменениями.
Первый пример использования. Люди стали жаловаться на скачки остатков на складе ("утром смотрю — 10 шт, в обед смотрю — 5 шт, а я уже клиенту пообещал, а я не дурак, вижу что движений не было неделю"). Бухгалтерия говорит — мы нипричем, все документы оформляются в течение суток, никаких исправлений задним числом. Смотрим в механизм — вуаля, остатки сегодня меняются, потому что изменились обороты за предыдущий месяц. Ковыряем — бухгалтер ввел новый документ месячной давности. Спрашиваем — ты чего? Не успеваю, говорит.
Второй пример использования. Я фиксировал данные о продажах — просто потому, что на этой области данных тестировал механизм. Считалось, что данные о продажах меняются максимум неделю, и то в редких случаях, когда допущены ошибки. А тут смотрю — изменились продажи прошлого месяца. Сами понимаете, за прошлый месяц уже менеджер по продажам уже премию получил. Вижу, что бухгалтер изменил — ты чего, говорю? Оказалось, менеджер заставил, потому что сам перемудрил, клиента запутал. После этого случая бухгалтер так делать перестал.
Вопросы для контроля
Функционал контроля задач, проектов и т.д. есть, например, в 1С:Документообороте, наверняка многие видели. Там вы можете любой (или почти любой) объект поставить на контроль, установить дату, и у вас выскочит напоминание.
Мне типовой не понравился, т.к. он не позволяет делать контроль многоэтапным — например, сделать так, чтобы напоминание выскочило 10 раз с периодичностью в неделю. Поэтому я сделал свой простецкий механизм, основное отличие которого — он позволяет вести историю контроля, и растягивать его на какой угодно срок.
Например, я инициирую изменение в бизнес-процессах. Пишу соответствующие письма, провожу встречи и т.д. Записываю себе в систему этот вопрос, ставлю точку контроля — через неделю, пишу комментарий типа "переспросить Васю". Через неделю вижу напоминание, переспрашиваю Васю, Вася говорит "ааа, слушай, у нас завал, пока некогда". Ок, говорю, ставлю следующую точку — через неделю. Вижу напоминание, захожу — вижу историю. Переспрашиваю Васю, у Васи опять завал. Говорю — Вася, ты это уже говорил. Вася клянется, что это было в последний раз. Через неделю движение все-таки начинается.
Выглядит, как ерунда какая-то банальная, и вроде все это почтой можно разрулить, но, как сказано в начале статьи, на истину не претендую. Применение этого инструмента и подхода несколько раз меня выручало, когда банально нужно добиться чего-то от людей, которые тебе не подчиняются, поставить задачу ты им не можешь, а идти через верх в данной конкретной ситуации не по-пацански.
а плюсану ка сабж
(1)в рот мне ноги, что за день )
В той или иной форме, кто занимается внедрением в больших фирмах или поддержкой, с подобным сталкивались и ключевые механизмы — это бэкапы и в большей степени версионирование, а дальше уже конкретно отталкиваясь от проблемы придумывают свои механизмы сбора статистики. Обычно демонстрация 1-2 раза косяков ответственным со стороны заказчиков закрывало проблему. Про такое всегда интересно почитать, спасибо!
В 90% процентов случаев, когда возникал вопрос «кто-то изменил мои документы», это сделал сам гневающийся проситель.
Журнал регистрации + бэкап ежедневно.
приятная статья. читал и понимал, что то это мне напоминает. спасибо!
По поводу фиксации данных можно поподробнее
+ однозначно. Хорошие примеры и слог читается легко и не напряжно.
Статья интересная. Но многое смутило. Отрицательные остатки на 10 счете? Откуда? Почему не надавали по шапке ответственным бухгалтерам раньше? Тоже самое по 60-му счету. Это ведь должно проверяться ежемесячно. Продажи за прошлые периоды правят все кому не лень. Почему не закрываете прошлый период от редактирования? Почему продажник не резервирует товар как положено, а обещает клиенту только на словах? Почему ваш начальник склада не следит за работой кладовщиков? Все эти вопросы обычно можно решить без внедрения собственной системы слежки за пользователями. Если кто-то говорит, что проблема именно в автоматизации, то он должен предъявить доказательства своим словам. Если не может, значит проблем нет.
(0) отличная статья!
идеи похожи на
и все же своими словами по другому звучит 🙂
спасибо за труд!
Бывает интересней. Когда уже все, тупик. Идешь к руководству, а оно бессильно. Наказывать не наказывает, поощрать не поощряет.
Специалиста наказывать не хотят, а денег заплатить тем, кто пашет — нет. В итоге складывается ситуация, когда работать не хочет никто. Т.к. нет разницы. Как правило, в такие моменты, один (хороший, работящий) увольняется, а второй (плохой, ленивый) остается.
Да, ноют все. По поводу и без повода. Врут тоже все. Косячат тоже все. Политических игр предостаточно. Пока носом не ткнешь не сознаются.
Очень хорошо всплывает факт безразличного/халатного отношения большинства сотрудников к данным, когда начинаешь автоматизацию. Особенно хочется задать вопрос руководству — куда смотрели, когда ваши бухгалтера «рисовали» цифры? И директор ты или не директор, что ни разу не зашел в 1С просто посмотреть как выглядит работа твоих сотрудников изнутри, какие отчеты есть? Или по-старинке созвал совещание с вопросом «У нас все хорошо? — Хорошо! — Ну тогда хорошо.».
Все очень жизненно и толково. Паттерны «Запись действий пользователя с временными показателями», «Запись значений показателей», «Фиксация данных» тоже реализовывал.
Замечательная статья, теперь знаю куда двигаться. Спасибо
Спасибо, очень понравилась статья и методы, которые применили. Буду применять.
(4) согласен. Просто в какой-то момент лень стало пользоваться версионированием, особенно когда надо найти изменения «где-то в прошлом квартале».
(8) к сожалению, иногда складывается ситуация «докажи, что ты не верблюд». Складывается по политическим соображениям. В моем случае зачастую из-за чрезмерной активности — получаешь такую вот мелкую месть. Говоришь — друзья, докажите, что я не прав. Они сопли жуют, «так а чо, мы-то как, ты сам посмотри в системе». И руководитель с ними соглашается — «ну да, наверное врут, но проверить только ты можешь».
Поэтому, раз отмазаться нельзя, приходится автоматизировать.
(6) я сделаю публикацию, скорее всего.
(10) да, такое бывает. Я за то, чтобы разрывать порочный круг (
Иван,привет!Описанные случаи тобой жизненные, сам сталкивался с подобным.
Жаль терять драгоценное время на борьбу с «ветряными мельницами» в такой ситуации.
Тут важнее влиться в коллектив,добиться уважения коллег по работе.
(18) описанные методы — скорее вспомогательные, для борьбы с засранцами, которые найдутся всегда и везде.
Вроде так: раз иногда все равно приходится работать с засранцами, почему бы эту работу не автоматизировать?
Конкретно в моей ситуации основная причина, почему так делать приходилось — текучка кадров в других службах. Наладишь работу с одним главбухом, он уйдет по независящим от меня причинам, приходит другой, и все заново. Очень редко новый руководитель продолжает линию предыдущего, это часть правил корпоративных игр — надо играть на разнице себя и предыдущего руководителя, иначе тебя не будут уважать.
Логи — наше всё!
(20) я бы сказал так: логи — это гигиена. Как зубы чистить.
Спасибо за статью, очень интересно!
Правда ожидал в конце увидеть обработки/разработки или ссылки на примеры )
(22) почти все упомянутые инструменты легко воспроизводимы. Если они вам нужны, то вы получите удовольствие для ума, воспроизводя их.
Исключение — фиксация данных, ее постараюсь воспроизвести сам и выложить.
(8)Пример из практики — очень большая компания. Внедрили 1С. Через 2 года работы оказалось, что у них просто громадные минусовые остатки по некоторым регистрам. Они туда просто не смотрели. Потом обратились: «как это всё закрыть?»
(0) Интересная статья, плюсанул. Только вот не могу согласиться с тезисом
.
Очень даже по-пацански. Не раз встречался с ситуацией, когда пользователь просто саботирует твои разработки, не пользуется ими и перекладывает всё на тебя (потому что предыдущий программист сам всё это делал). В этом случае, единственный пожалуй вариант — идти к руководству и объяснять, что я автоматизирую процессы для того, чтобы пользователи могли самостоятельно пользоваться результатами этой автоматизации. Как правило, после беседы с руководством, пользователь сам приходит и просит обучить его пользоваться разработанным механизмом. Ну и, конечно, руководство тоже должно быть адекватным и понимать, что ты хочешь до него донести.
(25)
это я виноват, коряво написал, сейчас исправлю.
Имелось в виду что идти на верх не по-пацански в данной конкретной ситуации.
Например, когда мы с Васей так-то дружбаны, просто он валенок немного и ничего не делает с первого раза.
Такая ситуация происходит почти в каждой организации при внедрении новых механизмов или каких то схем учета.
Против саботажа можно бороться только конкретными фактами подтверждающие действия пользователя.
У меня в конторе до поры до времени это было сплошь и рядом. После того как на разборах полетов предоставил конкретные данные по действиям сотрудников, кто что делал и не делал, саботаж прекратился.
Да и руководство организации выдало всем саботажникам пилюль от кашля, так для профилактики.
Статья интересная благодаря реальным примерам из жизни. Но не соглашусь с автором по методологии работы.
Замечательно иметь механизм позволяющий оценить использование программного решения, но желательно и смотреть на проблему с позиции пользователя. Есть множество примеров когда разработчики неудачно реализуют функционал и потом нагибают пользователей.
А из статьи следует, что работаете по принципу спец агента в стане врагов — разведал нашел косяки слил руководству. Подкрепляя все это логами и бекапами. Нервные внедрения получаются.
На месте руководителя при выборе из продвинутого и покладистого программиста, выбор будет в пользу второго номера.
(27) у меня так не прокатывало, чтобы раз и навсегда. В основном из-за текучки во всех эшелонах.
Это, наверное, главная причина появления таких инструментов — чтобы не повторять один и тот же путь заново.
(28) не совсем так, это инструменты скорее для защиты, чем для нападения.
На тот случай, когда на тебя каких-то собак повесить пытаются. А ты — раз, вот факты и цифры. Потом успокаиваются, перестают пытаться уронить ИТ-отдел, сидя на хромой кобыле.
Начинают другие методы использовать, до моих рваных джинсов докапываться.
(30)
когда аргументы заканчиваются, обычно переходят на личности 🙂
(31) да, увы.
(28)
К сожалению так бывает когда учет в компании был не прозрачным и всех устраивал существующий хаос. Все это было только по одной причине: прибыль компании покрывала все ее убытки с лихвой и руководство особо не заботила оптимизация или правильный учет.
А потом случился кризис, и руководство начинает вникать в суть происходящих дел в организации, а не просто считать сколько они заработали.
Вникают куда уходят средства, что мы покупаем и по какой цене, вовремя ли платят нам контрагенты.
В данной ситуации руководство компании готово уволить несговорчивого сотрудника и взять на его место другого.
В данной ситуации программист реально становится шпионом в организации, на которого все косятся, потому что знают, если пользователь сильно накасячет и руководство этим заинтересуется, то программист выложит на стол руководству всю аналитику для принятия решения.
(29)
У нас все это началось в кризис, в добавок мы потеряли крупного клиента, который приносил порядка 40-45% от всех доходов. Поэтому, руководство было само заинтересовано в наведении порядка. У нас руководителей различных направлений по увольняли (сменили), финдиректора и еще кучу народа.
А до этого времени было тяжко, руководству было не интересно. Они смотрели только сколько они потратили и сколько заработали и если сумма прибыли их устраивала, то все остальное их не интересовало. И ни какой поддержки с их стороны при внедрении учета не было.
Статья полезная. Может на будущее, что-нибудь из идей автора реализую у себя. Мне год назад при внедрении необходимо было отследить — кто реально работает с базой данных. Для этого в подписку на событие ПриЗаписи вставил такой небольшой код. Потом для руководителя сделал простенький отчёт на СКД. Сразу стало видно, кто есть кто и чем занимается.
(35) а стандартный журнал регистрации, чем не угодил?
Там же видно, кто какие документы правит?
Т.е. сам факт изменения документа фиксируется.
Статья о том, как вызвать ненависть к программисту всего персонала организации..
Но неплохая.
(37) в моем случае — о том, как защищаться от вызванной ранее ненависти.
(36) Стандартные журналы регистрации, как правило, периодически отрезаются.
(38) Можно держать вектор ненависти персонала в своих руках. Например в корпоративном чате корректировать сообщения сотрудников друг другу, а потом показывать «правильные» логи. Их, как и логи описанной программки, потом никто не оспорит.
(40) наверное, возможно, не знаю. Управлять перепиской — перебор для меня.
(41) Это сложно только в первый раз.
(42) дело не в сложности. Мы ж тут про пользу дела рассуждаем, а не про управление взаимоотношениями других людей друг с другом.
Если знаете сценарий, при котором ваш метод принесет пользу бизнесу или программисту — рассказывайте, интересно почитать.
Спасибо за статью.
Тоже была ситуация. Конфликт с бухгалтерией по обновлениям базы после окончания рабочего дня. Работали до 18, в 18-30 я начинал обновления. Прилетает жалоба, что программист работать не даёт со своими обновлениями, приходится до 21-00 оставаться. Руководство говорит, делай обновления после 20-00. Мне это естественно не улыбалось. Сделал отчет по журналу регистрации, где видно что новые документы начинают бить ближе к концу рабочего дня (часов в 16), до этого сильной активности в базе нет. В итоге меня оставили в покое, а у бухов поинтересовались, что же они весь рабочий день делают.
Полезная статья. Полезная своими наглядными примерами, где можно такие моменты использовать.
Плюс автору. Прочитал с удовольствием.
Скачка остатков легко лечится закрытием старых периодов для ВСЕХ !!! Заметил, что автор статьи ушел далеко от самой 1С — он уже сильно бухгалтерию знает и это его спасает от дурацких наездов и глупых задач. В принципе, так и должно быть, когда имеешь дело с учетом. Чаще всего происходит перенос проблем с больной головы на здоровую : все косяки бухгалтеров, операторов и менеджеров сваливают на программистов — это очень достает и с этим надо регулярно бороться.
(46)
какое-то время да. Потом, как вы сами пишете ниже, программисты опять будут виноваты — закрыли нам месяц, не дают исправить, не хотят работать, им же там все цифры видно, чо не могут отследить где что поменяется, да они тупые просто, только и могут, что права забирать, да кто они такие вообще, будут меня учить как мне бух.учет вести, давайте вон ту фирму наймем, там ребята мне раньше здорово помогали и все красиво было, и т.д., любой из нас продолжит этот список.
(47) Когда сдан баланс, какие могут бьlть движения назад ? Тут сам главбух должен руководить правильно.
(48) должен-то должен, но когда припрет, виноват будет все равно программист. Даже если сам главбух управляет границей запрета. Вы не попадали в такую ситуацию? Я попадал. Бухгалтерия — очень, очень странный народ.
И еще особенность есть — бухгалтерия не однородна. Иногда исправить ошибку в закрытом периоде надо рядовому бухгалтеру, но она боится обращаться в главбуху, и упрашивает программиста. Программист — порядочный, он не соглашается. Ошибка не исправляется вовремя, потом это обнаруживает главбух, и все равно виноват программист.
Надо держать ухо востро с этими дружбанами.
Автору респект за статью. Иметь факты в кармане всегда лучше, нежели не иметь их вообще.
Когда совещание у руководителя, а, тем более, если разбор полетов, то все высказывания, подкрепленные цифрами, даже не оспариваются.
И в каком бы Вы дружном коллективе не работали, когда речь заходит о депремировании, поиске виноватого, повышение по карьерной лестнице или любой иной выгоде, то без фактов никуда.
Да, проблемы те же. Обвинения за всех и вся. Честно говоря, я пока не в состоянии написать такую программку. Нужна, что бы фактами отвечать. Можете поделиться, хотя бы простым вариантом или посоветуете готовое, (не бесплатно)?
(51) вы про какую программу?
(52)Я по статье «Экзорцизм программистскими методами» — Запись действий пользователей с временнЫми параметрами в 1С, журнала регистрации недостаточно.
Друзья, прошу прощения за спам — поучаствуйте в .
(8) Всякое бывает же. Зарплаты низкие, процессы не отлажены, начальники разгильдяи и т.д. и т.п. Поверьте, очень многие конторы не могут закрыть период. Да, конечно же приходят пальцегнутые умники, которые шашкой машут, но через короткое время сливаются и убегают с позором. В общем зря так категорично судите людей.
спасибо за отличный текст. Очень интересный опыт
Спасибо автору за очень интересную статью. Показал, на что нужно обращать внимание и описание инструментов. Плюс, однозначно.
Механизм «Фиксация данных», упомянутый в публикации, вошел во флакон —
(10)По поводу плохих и хороших спецов — это уже плохое руководство, чтобы поощрить хорошего спеца можно и уволить плохого, а его з/п — как раз перевести на поощрение тех, кто «пашет».