Дыра в заборе, Эффективные менеджеры и Инженеры


    — Итак, ситуация. – начал Сергей. – У нас несколько пользователей, бухгалтеров. У всех – полные права. И кто-то из них, вероятно, нам гадит в учете. Что делать?

    — Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?

    — За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.

    — А, точно… — не стал спорить Стас. – Ну, и что?

    — А то, что перед нами классическая дыра в заборе. – многозначительно поднял вверх указательный палец Сергей.

    — Мать честная… — улыбнулся Стас. – Классическая дыра в заборе! Это в каком же трактате написано про классическую дыру в заборе?

    — Сейчас мы с тобой этот трактат напишем. Усаживайся поудобнее.

    — Я весь внимание. – кивнул Стас.

    — Представь ситуацию. Завод, окружен забором. Ну, из сетки, как она там называется… Из проволоки такая…

    — Сетка рабица. – подсказал Стас.

    — Да, наверное. И вот в этом заборе обнаружили дыру. Что делать?

    — Погоди, ты сейчас фантазируешь? – спросил Стас. – Или реальную историю рассказываешь?

    — Ну, вообще, реальную. – нахмурился Сергей. – А что?

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

    — Ладно. – улыбнулся в ответ Сергей. – Короче, это мне тесть рассказал. Он начальником завода работает. Не суть. В общем, нашли они дыру в заборе. Что с ней делать?

    — Хм… Может, залатать? – Стас изобразил искреннее рвение.

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

    — А, вон ты про что… — сконфузился Стас. – Ладно, давай дальше рассказывай.

    — Они сделали засаду. Сначала хотели камеру поставить, потом подумали – нафига. Мероприятие-то на несколько дней всего, потом камера не нужна будет, все равно дыру заделывать.

    — Засада – это самое оно. – покивал головой Стас. – Я сериал про полицию смотрел, они там тоже так делали.

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

    — Уборкой территории? На заводе? – удивился Стас. – Я думал, там только субботники территорию убирают.

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

    — Окэ, давай дальше.

    — Посадили в засаду охранника и, вроде, даже начальника охраны. Чтоб попредставительнее было. Указание было такое: как кто в дыру полезет, ловить и тащить на допрос.

    — О, такое было в фильме, как его… «Турецкий гамбит». – опять влез Стас. – Помнишь? Они там слух пустили, что секретное оружие есть в армии, и засаду посадили. Хотели поймать того, кто полезет смотреть.

    — Поймали?

    — Не, не поймали. Но побегали изрядно, удовольствие получили.

    — Ну ясно. А тут – поймали. – Сергей многозначительно замолчал.

    — Ну, и что? – нетерпеливо спросил Стас. – Кого поймали?

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

    — А в сумке что?

    — Смеяться будешь. – сказал Сергей и улыбнулся.

    — Ну давай, не томи.

    — Пять освежителей воздуха и три рулона туалетной бумаги. – засмеялся Сергей.

    — Твою ж мать. – засмеялся Стас. – Во попадалово. Ладно б там лом, или запчасти, а то туалетная бумага.

    — Ну, валенок какой-то. – сквозь смех сказал Сергей. – Ходил, собирал по туалетам, и таскал домой.

    — Нафига ему столько освежителей? Вместо дезодорантов что ли использовать?

    — Нафига, не нафига… Шоб було.

    — Вот дебил… И что, чем кончилось?

    — Чем-чем, уволили к чертям собачьим. Разнорабочий оказался, не ценный сотрудник.

    — Еще кого-то поймали? – Стас уже прекратил смеяться.

    — Да, так, по мелочи. Перед обедом тетка какая-то хотела вылезти. Сказала, что ребенка на тренировку надо отвести, там в 11 часов начало, а обед – в 12. Начальник не отпускает, вот она и бегает через дыру, чтобы не КПП не отмечаться.

    — Тоже уволили?

    — Не, тесть сказал – хорошая тетка, давно работает, он ее давно знает, еще когда сам в цехе работал. Поговорил с ее начальником, велел отпускать, просто обед ей сдвинули. Ну, ребенка отводит, потом дома обедает, и к 12 часам возвращается. Она прям рада была.

    — И все? Или еще кого поймали?

    — Больше не стали, залатали дыру и велели охране ежедневный обход забора делать.

    — Понятно, ладно. – покивал Стас. – Нам-то это чем поможет? Тоже засаду на бухгалтерию устроим?

    — Ну да. Возвращаемся к нашей ситуации. Есть дыра – полные права у всех.

    — Вообще, странная дыра, конечно… — задумался Стас. – Наверное, только у нас такое.

    — Не, не только у нас. – помотал головой Сергей. – Я когда в компании-интеграторе работал, часто такое видел. Особенно, когда контора небольшая и программиста нет. Просто просят всем полные права дать, чтобы работа колом не вставала, если что-то не получится. И вообще, не перебивай.

    — Все, молчу. – Стас примирительно поднял ладони.

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

    — Так, это уже интереснее. – не выдержал Стас. – Давай, давай, рассказывай.

    — А чего рассказывать… — пожал плечами Сергей. – Все просто. Первое – надо добавить возможность изменения прав на лету. Ну, чтобы можно было за пару секунд забрать, и наоборот – дать. Без перезапуска программы у пользователя.

    — Понял, это несложно.

    — Да, несложно. Сегодня сделаем. Дальше. Делаем права точечными, максимально точечными.

    — Это как?

    — Раз речь о складе, то так: назначаем индивидуально на каждый склад, и каждый вид операции. Они же не все подряд делают все операции? Одна делает отгрузки, другая – поступления, и так далее. Вот и мы такую настройку обеспечим.

    — А по складам зачем делить? – нахмурился Стас.

    — Затем, что у них и по складам ответственность делится. – терпеливо объяснял Сергей. – Одна работает, например, с цеховыми складами, другая – нет. А сейчас, пока настройка не точечная, мы понятия не имеем, кто с каким складом что делает.

    — А, теперь понятно.
    — Ну все. Главное – чтобы можно было на лету менять. Начала она документ делать, раз – нет прав. Она сразу жаловаться. Если мы быстро дадим права, и она просто доделает документ – отлично, скандала не будет.

    — Во, а мы как решать будем, кому давать, а кому нет?

    — Маленький допрос устроим – кто такой, то есть кто такая, чего делаешь, нафига, почему именно ты, а не вон та прелестная девушка, ну и так далее.

    — Так скандалить начнут все равно. – покачал головой Стас. – В чем смысл-то?

    — А мы бумажку какую-нибудь сделаем, и у Курчатова подпишем. Типа ревизия прав доступа. Раз ты упомянул «Турецкий гамбит», помнишь там бумажка была? Всякий подданный, всякого звания, обязан оказывать подателю сего полное и безусловное содействие.

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

    — И получим очередной год, в котором не решена проблема склада.

    — Да почему? – всплеснул руками Стас.

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

    — А, ты опять про свое системное мышление… — скис Стас.

    — Опять, а что такого?

    — Да так я…

    — Чего так, Стас? Ты что, думаешь, мы тут в игрушки играем?

    — Да нет, конечно. Просто как-то это… Не по-настоящему, что ли. Вроде все понятно, теория красивая, а как работать – непонятно.

    — Смысл не в теории, а в ее применении. – немного агрессивно ответил Сергей. – Теорию все знают, а толку-то? Вот Курчатов наверняка читал системное мышление, и еще кучу умных книжек. Видел же полку с книгами в коридоре?

    — Как будто он их все читал…

    — Все читал! Ты не знал, что ли? Он постоянно покупает и читает книги всякие, для бизнеса. Потом ставит на полку, чтобы остальные читали. Не знаю, берет кто-то или нет, но сам-то Курчатов читал. И где он?

    — Не знаю, у себя в кабинете вроде. Или в аэропорту, он вроде в Германию собирался.

    — Его нет здесь. Не в нашем кабинете, а в проекте. Потому что он не знает, что делать. Теорию знает – попроси рассказать, например, про системы, он красиво и убедительно тебе все по полочкам разложит. А как применить эти знания – не знает.

    — Почему?

    — Потому, что он не инженер, а менеджер.

    — А инженеры тут причем вообще?

    — При том, что изучение методов и их применение – работа инженера. Понимаешь? Вот ты же изучаешь новые технологии?

    — Ну… — потянул Стас и улыбнулся.

    — Да изучаешь, я знаю. Когда с чем-то новым сталкиваешься, задачей там необычной, или еще чем. Что делаешь?

    — Раскуриваю, мануалы читаю, практику, статьи.

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

    — А они – не так, что ли? – удивился Стас.

    — Не так, в том-то и дело! У них потоки теории и практики не пересекаются, каждый живет своей жизнью. Ну, знаешь, как у преподов в институте. Смотришь – вроде все знает, электронику, например, а если вытащить на завод – в лужу сядет.

    — Так уж и сядет…

    — Не все конечно, бывают толковые преподы, с большой практикой, но есть и откровенные бездари. Мне препод, у которого я диплом делал, как-то сказал такую шутку: не умеешь работать – иди в преподаватели.

    Даже случай один был. Двое парней делали диломный проект, на заводе. Сделали какую-то штуку, не помню точно, ну девайс короче, электронный, для производства. Не просто спроектировали, а собрали, применили, и вполне удачно, даже вроде запатентовали.

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

    — Мда… — задумчиво пробормотал Стас.

    — То же самое с эффективными менеджерами, один в один почти. Знают много, рассказать могут, на семинаре выступить, некоторые даже консультантами подрабатывают. Любую теорию тебе красиво изложат, статью напишут, а как до дела дойдет – пфффф.

    Сделать ничего не могут, только приказы раздавать налево и направо. Внедрить 5S! Внедрить Lean! Внедрить CRM! Применить методы системного мышления!

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

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

    — Ну, а что не так-то? – непонимающе покачал головой Стас. – Вот и сделал он систему.

    — Да не систему он сделал, а коробку развернул! – раздраженно ответил Сергей. – Как конструктор сайтов, я не знаю. Или коробочную информационную систему. Или бизнес по франшизе. Он вообще не понимает, как это все работает. Фурычит как-то, и все. А если не фурычит – надо просто заорать погромче. Или людей уволить, даже если они ни в чем не виноваты.

    Понимаешь? Вот ты сделал систему – информационную. Можешь поступать, как программист из анекдотов – работает, и все, не трогайте ничего. А потом – бац! – и перестает какой-то кусок у тебя работать. Ну, или, проблемы с производительностью начинаются, например. Что делать будешь?

    — Запущу отладку с замером производительности. – кивнул Стас.

    — Да, запустишь, найдешь узкое место, и попытаешься понять, что там не так. Например, запрос кривой у тебя, выполняется полминуты, а должен – полсекунды. Что делать будешь?

    — Поменяю его, рефакторинг сделаю.

    — А менеджер на него наорет! На запрос! – агрессивно сказал Сергей. Стас в ответ улыбнулся, и агрессию Сергея как рукой сняло.

    — Твою мать, ну и аналогии у тебя… — смеялся Стас.

    — Так оно и есть! – ответил Сергей. – Или уволит запрос. Или другой запрос вместо него поставит. Или расскажет запросу, что тот – мудак, не любит компанию, ведет себя отвратительно, и вообще, почему одет не по форме?

    — Блин, тоже верно. – Стас уже не мог остановиться. – Или поговорит по душам с запросом, по какой-нибудь методике, типа Дейла Карнеги.

    — Ага, точно. Но это – только в том случае, если он хоть чего-то умеет. Целенаправленно врать – это ж уже осознанное.

    — А, ну да…

    — А поделать он ничего не может. Точнее – не хочет. Хотя все методы знает, если он – эффективный менеджер. Потому что двуликий, как Янус. Или, как говорят в деревне, ни рыба, ни мясо. То ли боится, то ли лодку раскачивать не хочет. Максимум – поручит кому-то из подчиненных, а сам будет поглядывать, советы свои долбаные давать.

    — Как Курчатов тебе поручил? – хитро прищурился Стас.

    — Ну да… — осекся Сергей. – Точно, блин! Так он в первый раз правильно поступил! Понимаешь? Раньше ведь он кому поручал?

    — Главбуху, еще кому-то…

    — Вот! Менеджерам опять же! И у них ничего не получилось! А мы с тобой – инженеры, и у нас получится!

    — Ну, не у нас, а у тебя. – поправил Стас.

    — Да не придирайся к словам. – махнул рукой Сергей. – Мы с тобой историю творим! Если получится со складом… Точнее – когда получится со складом, поймет Курчатов, кому надо поручать наведение порядка, понимаешь? Кто должен изменения в системе делать?

    — Инженеры. – картинно кивнул Стас.

    — Инженеры! Правильно! – воскликнул Сергей. – А эффективные менеджеры – это просто пользователи системы, пусть и с руководящими полномочиями. Ну, как заказчики доработок информационной системы. Вроде как они – владельцы своей части программы, но при этом изменить в ней ничего не могут. Обращаются к кому?

    — К нам, программистам.

    — Да, к нам. Мы вносим изменения, они продолжают пользоваться. Почему так же не делать с остальными системами? Раз сами не могут, не умеют, не решаются, будем мы изменения делать! Нам не нужны полномочия, власть, понимаешь? Мы не забираем их хлеб, мы не будем проситься в начальники склада, когда победим его проблемы. Просто починим, и уйдем, дальше в носу ковыряться.

    — Звучит заманчиво. – прищурился Стас, как довольный кот. – Отдел изменения бизнес-системы. А руководители – наши пользователи. Дело за малым – навести порядок на складе.

    — Да, это само собой. – кивнул Сергей. – Возвращаясь к нашим баранам. Так, ты делаешь систему быстрой настройки прав доступа. Так?

    — Так.

    — А я пока…

    Что там Сергей собрался пока делать, никто не узнал, потому что дверь в кабинет распахнулась, и в нее вошли двое – бухгалтер Даша и кладовщик Рустам.

    — Что, опять? – вздохнул Стас.

    — Опять! – крикнул Рустам. – Задолбались уже!

    — Что там у вас опять? – недоуменно спросил Сергей.

    — Да… — махнул рукой Стас. – Давайте сюда свою бумажку.
    Поделиться публикацией

    Похожие публикации

    Комментарии 61
      +2
      — Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?
      — За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.

      Use grep, Luke!


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

        +8
        и не говорите. Те еще дятлы.
        Я не с ними, если что.
          +2

          Если проблема длится годами, а при попытке закрыть топорным методом в лучшем случае заметаются следы, то проблема активна и присутствует в настоящий момент. То есть, кто-то лезет не в своё дело слишком часто. Я бы, пожалуй, тут не просто "точечно права повыдавал", а ещё и с флагом audit, то есть, если прав у пользователя реально нет, система действует так, как если они есть, но логирует действия. SELINUX=permissive такой.


          Вообще, проблема в том, что они не знают, что им искать. "Как" — use grep, Luke, а "что" — а хрен его знает, на непосвященный взгляд все действия являются валидными. Судя по описанию, прямого уничтожения записей в этом случае нет, т.е. злонамеренные действия не выпирают из БД вот прям явно. Систематизировать права доступа — хороший ход, но проверка корректности их применения должна быть двойной — админ смотрит, кто нарушает, и идет с этим к управляющему системой с той стороны с вопросом "положено ли вот этому пользователю вот такие вещи творить", и корректирует права с аудитом сообразно полученным данным. При подозрении на мухлёж со стороны управляющего — к директору, если уже он мухлюет, то стараться смысла нет, и пора валить (с).

            +2
            Я бы, пожалуй, тут не просто "точечно права повыдавал", а ещё и с флагом audit

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


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


            Вообще, проблема в том, что они не знают, что им искать. "Как" — use grep, Luke, а "что" — а хрен его знает, на непосвященный взгляд все действия являются валидными.

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


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

              0
              в логах уже отражены похождения всех пользователей за несколько лет (то есть аудит уже ведётся)

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


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

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


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

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

          +4
          Подумаешь, переписать систему прав доступа…
          Подумаешь, поставить весь процесс раком, ведь каждый бух для каждой операции должен будет в IT-отдел на поклон идти…
          Подумаешь, после второго-третьего раза это будет отменено с самого верха…
            0

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

            0

            Ура, прода!

              +1
              Права дать и индивидуальные пароли для записи новых/изменения старых документов.
              Вылазит косяк с какой-нибудь единицей хранения/учёта — смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период. Когда и если источник проблем будет локализован, показательный расстрел и изъятие лишних прав у остальных. Всё на правах ИМХО.
              P.S. За цикл статей спасибо, хорошо написано.
                0
                иногда достаточно требовать при записи документа сильно задним числом объяснения, почему этот документ изменяется, кто виноват в несвоевременной актуализации документа, и с кем из руководства это согласовано. после этого список измененых «в глубокой заднице» документов начинает сокращаться…
                  0
                  Не, нам же надо отловить, кто через дыру в заборе шастает туда-сюда, а потом уже зададим вопрос отловленным — «А с какой целью, товарищ, вы мимо проходной тропу протоптали?», а вы предлагаете на этой дыре ещё одну проходную поставить поставить.
                    0
                    ну вообще, конечная цель — «навести порядок».
                    выяснять причины, конечно, нужно. без этого не обойтись. но иногда эти причины достаточно субьективные (не успела-забыла-не подумала о последствиях).
                    и проблемы _предотвращаются_ тем, что пользователь понимает: косяк будет зафиксирован, косяк придется как минимум объяснять, а то и отвечать. И возникает дилемма: косячить по-минимуму, или накосячить и свалить.
                  0
                  А зачем здесь первый пункт с изменением прав?
                  смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период

                  Всё это можно делать и не обрезая права. Точнее даже сказать, что это вообще не связанные вещи: изменение прав и аудит.
                  +4
                  Какой-то длинный текст полный глупых идей и нелепых аналогий. Если есть проблемы с конкретными документами и есть логи, то можно просто посмотреть логи по этим документам. А вот с точечными правами мысль вообще не ясна. Зачем? Посмотреть кто работает с проблемным участком? Так опять же это можно увидеть в логах. Если там нет такой информации, то нужен нормальный аудит.
                  И опять же исходя из этого аналогия вообще не к месту смотрится. Дырка в заборе — это когда у человека нет прав, на то, что бы входить/выходить, но он находит путь в обход системе разделения доступа. А в данном случае все ходят через проходную, но предлагается на этой проходной ворота не открывать, пока человек не скажет куда идёт.
                    0
                    Как я понял, сейчас там нет вообще никакого разделения прав
                      0
                      Нет разделение прав есть, судя по фразам
                      Есть дыра – полные права у всех.

                      Просто просят всем полные права дать, чтобы работа колом не вставала, если что-то не получится.

                      Т.е. просто у всех root права
                      Насколько я понял нет нормального аудита и его отсутствие хотят заменить точечными правами. Например, проблема с документом 5X-18, а к этому документу имеет права доступа только Катя, значит она и косячит.
                      В общем, самый что ни на есть костыльный способ решения проблемы.
                        +2
                        Тут проблема, скорее всего, не в области исполнения прав и обязанностей, а в том что эти права и обязанности не были правильно настроены.
                        Примеров такой ситуации есть масса:
                        Кладовщику никто не вменил в обязанности списывать детали в момент отгрузки, он их отмечает скопом в конце недели, когда его никто не беспокоит.
                        В системе отметок нет, поэтому начальник производства или логист выкручиваются как могут, например могут по косвенным признакам — отгрузка заказа, понять что детали со склада ушли. И они закрывают заказ целиком, автоматически проставляя отметку что детали со склада ушли. Вроде все нормально, но потом окажется, что детали со склада не брали, а так как было срочно, а кладовщика(или деталей) не было — взяли с менее срочного заказа. Но по этому менее срочному заказу детали уже списаны со склада и по текущему получается тоже. А по факту со склада ушел только один комплект, а не два.
                        На следующей неделе нач.производства приходит за недостающей деталью, а ему кладовщик говорит, что дать еще не может. И вообще по его системе все уже выдано и предлагает нач. производству оформить акт брака на уже выданное и он по нему выдаст недостающий комплект. Нач.производства такое устроит, а вот по документам со склада ушло три комплекта, а по факту два.
                        Что будет в конце месяца при аудите? Излишек. Но это же в плюс кладовщику, так что его вроде как наказывать не за что. А если выдается очень много деталей то концы найти очень и очень тяжело. А если за кем-нибудь еще и косяк будет, то почти невозможно, так как еще и следы будут скрывать. Только засаду готовить и остается.

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

                        Здесь вопрос в организации и координации. Кто что делает, для чего(какой будет результат), оценены риски и проблемные точки, как именно будут решаться конфликтные и форсмажорные ситуации. Если это прописать тогда уже будет вопрос по правам доступа. А иначе получится автоматизация бардака и борьба с поносом запиранием туалета))))
                        Ну а после естественно вопрос контроля. Все ли участники системы работают как запланировано.
                    +2
                    Подозреваю «дырка в заборе» — это Стас, который бухгалтерам и кладовщикам меняет данные задним числом, потому что «нада».
                      +1
                      меняет данные задним числом


                      А что в этом плохого? Ошибки исправляются, коррекции вносятся.

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

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

                      Отсутствие аудита и истории изменений — вот это плохо.
                        0
                        плохо то, что данные, уже полученные после даты измененного документа, становятся некорректыми. (естественно, не все — но четкого механизма понимать, что конкретно стало неверным — я не видел). а на основе этих данных были уже приняты управленческие решения.
                        Требовать безошибочности нельзя. но свести раздолбайство к минимуму — надо стараться.
                          0
                          Удваиваю. Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.
                            0
                            Вообще-то в нормальной бухгалтерии так и делается, и делалось всегда до компьютеров.
                              0
                              Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.

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


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


                              Самое важное: система должна быть для людей, а не для формальностей. git позволяет изменять историю. Да и все остальные системы тоже. И это не просто так.

                                0
                                а для каких именно людей?
                                вот реальный пример: продажникам дали задание срочно слить остатки товара. продадут — премия. они — выполнили. а у бухгалтера «в пятницу была запара», и он «не успел оформить приход». оформил в понедельник. ничего страшного — продажники требуют заработаную приемию, начальство не выдает, потому, что на остатках товар есть — и у конкурентов он появился более дешевый.
                                Или другой реальный пример: товар был бракованый (у всех региональных дистрибуторов, кстати — чисто производственный брак), списание «решили оформить потом» (оформим задним числом, ничего страшного), а система подтвердил заявку торговой сети на этот товар. как вы догадываетесь, на количество, которое обычно сеть брала у 3 дистрибов. штрафы за недопоставку до 50%…
                                такие привычные мелочи, как штрафы от налоговой за расхождение в учете, или съехавшую себестоимость, продажи «в ноль» или «в минус» из-за добавления задним числом накладных расходов я и не говорю — рутина…
                                так для каких именно людей из вышеперечисленного «система должна быть»?
                                  0
                                  Расследование проведено? Ошибка устранена? Товар продан? Если так, то зачем мешать работать? Или вдруг менеджер не знает про строгость бухгалтерской отчетности?

                                  В общем, в вашем примере система отработала как надо. А если люди поняли свою ошибку, то вообще всё классно, бизнес идет. Это лучше, чем отсутствие продаж, так как нет прав добавить документ в файл, а айтишник уже вечером пивко пьет вдали от компа.
                                  0
                                  git позволяет изменять историю.

                                  Дополню, что git, хоть и позволяет изменять историю, но очень противится этому. Если нужна существенно изменяемая история — лучше использовать что-то другое.

                                    0
                                    Если нужна изменяемая история — нужно ХОРОШО ПОНИМАТЬ, ЧТО ИМЕННО ТЫ ДЕЛАЕШЬ. В гите тоже не рекомендуют менять историю, и совершенно точно настоятельно не рекомендуют менять историю тех коммитов, о которых знает кто-то ещё. Оффтопик — вот если бы гит позволял в одной ветке красивую историю, а в другой полную, при этом начало и конец фрагмента указывали бы в обеих ветках на одинаковые места…
                                    back on topic: ведь правила бухучёта не просто так придумали, и сторнирование, и бухгалтерские справки…
                          +4
                          — Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?
                          — За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.

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

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

                              А что воровать по крохи и из-за объема получить существенную сумму нельзя?


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


                              Желание


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

                              Дыру в заборе заделали, но вот что не увидели....

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

                                  Да и к правам и логированию.


                                  А вот Х знакома с Y который шантажирует Z который является сотрудником компании W которая дорабатывает эту систему. И Z меняет данные не через оболочку программы, а сразу в базе. Логирование конечно есть, но кто же смотрит логирование V, когда все действия в оболочке программы логируются в ней.


                                  А вот сравнение может выявить и такой случай.

                                    0
                                    абсолютно согласен. в этом случае сравнение с сохраненными остатками позволяет вычислить факт правки данных. был случай — штатный программист правил данные прямо в БД по своим обедам (стоимость обедов вычиталась из зарплаты)…
                                0
                                У меня такая аналогия родилась:
                                Парк, в котором протоптаны куча дорожек. Администрация решает облагородить парк.
                                Выделяет деньги на асфальтирование дорожек. Нанимает дизайнера, тот разрабатывает схемы дорожек с точки зрения красоты. Прокладывают дорожки и недоумевают потом как так, почему люди продолжают вытаптывать траву по своим дорожкам. Начинают городить ограждения и прочее. А что мешало сразу разобраться почему именно здесь люди вытоптали дорожку, а не левее на пару метров?
                                Т.е. это не дыра в заборе, а забор не на своем месте.
                                  0
                                  а потом ларек с шавермой перенесли в другое место и сетка дорожек на следующий год совершенно другая стала…
                                    0
                                    Совершено верно, выяснив причины, можно принимать системные решение. В данном случае заранее выделить зоны под торговые заведения.
                                +1
                                Смешались в кучу… задачи мониторинга, прав доступа, реагирования на несоответствия, своевременного планирования IT инфраструктуры.
                                «Точечные права» у них появляются через годы существования проблемы, а решение — веселая «засада» (причем с предварительным информированием пользователей путем интервью) — як дити.
                                  +2
                                  Полные права у всех — это не дыра в заборе. Это отсутствие забора.
                                    0
                                    С одной стороны, тема отсутствия инженерного (системного) мышления у большинства линейных руководителей, вместо которого можно наблюдать набор религиозно-сектантских практик («делай, как я сказал»), очень актуальна. И описана она достаточно образно и точно.
                                    С другой стороны, концовка как-то смазана. И складывается впечатление, что руководители с системным мышлением оказываются обычными болтунами, когда у них самих дело доходит до принятия конкретного управленческого решения. А хочется больше позитива.
                                      0
                                      В руках у эффективного менеджера кнут и пряник. Кнутом он лупит подчиненных, если они косячат. Пряник ест сам.
                                      Система, которая легко и незаметно позволяет проводить чего-то задним числом… Выкинули бы ее, да завели амбарную книгу, раз не умеют ни в менеджмент, ни в безопасность, ни в аудит.
                                        0
                                        nmivan «Двое парней делали диломный проект, на заводе.» — оч интересно откуда эта история взялась… Потому что она о моем отце.
                                          0
                                          Город, ВУЗ, факультет, кафедру, фамилию преподавателя знаете?
                                            0
                                            Томск, ТПУ, Электроники (или Электротехники, уточню у него). Последние 3 надо уточнить.
                                            Завод ЗСМК. Тема диплома что-то связанное электронным реле, но я точно не помню.
                                              0
                                              нет, это не о вашем отце.
                                              Совпало просто.
                                                0
                                                Забавно, что даже оценка совпала)
                                          0

                                          Эм, а я правильно понял конец, что изменения, которые «гадят» в систему вносят сами разработчики? :)
                                          Или у меня извращенное мышление? :)

                                            0

                                            На самом-то деле Сергею и Стасу очень повезло. Они работают на настоящее производство. Завод, детали, рабочие, склад и сборка — это редкость в наше время.


                                            Большинство программистов клепают однотипные сайты с линиями в зайчик, либо поддерживают бекенд для оформления недельных кредитов на Java6. Bullshit jobs.

                                              0
                                              много 1с-ников работают на «реальную экономику». если не завод и цех, то по меньшей мере склад. Правда, многие из «тПру-программистов» считают 1с-ников «парапрограммистами»…
                                                0

                                                Хотя на самом-то деле всё наоборот ;-)

                                                  0
                                                  всё наоборот
                                                  На берегу реки доярка доила корову.
                                                  а в воде отражалось всё наоборот…
                                                  ©

                                                  ну а если серьезно — программисты нужны разные. и 1с — весьма неплохая платформа для решения определенного круга задач.
                                              0

                                              Вот он, узкоспециальный подход. Менеджер орёт, айтишник лезет в кофиги системы на горячую менять.
                                              И только службе безопасности никто не удосужился сообщить о фактах саботажа и знонамеренных действий. Да кто они такие, сами справимся, в чингачкуков поиграем, детство вспоминал им.
                                              Люди, человеки! Обо всех таких вещах нужно сообщать куда следует, а не заниматься самодеятельностью. Если СБ существует, конечно. Если нет — тады ой, сему месту бысть пусту.

                                                0
                                                а пока не установлено ни фактов саботажа, ни фактов злонамеренных действий. по ка только разбираются, планируют почитать логи перед сном…
                                                  0
                                                  Судя по тексту, факт саботажа установлен, причем в течении продолжительного времени. Т.е. версия мелкого хулиганства отпадает. Модель действий нарушителя — либо хищение (более вероятно), либо действие, инспирированное внешней силой (конкурентами, менее вероятно).
                                                  В любом случае это дело СБ.
                                                  Сегодня злоумышленник гадит по мелкому, завтра всю базу раком поставит и все предприятие парализует.
                                                    0
                                                    хотелось бы понять, откуда вы это взяли, как именно сделали такие выводы.
                                                    ибо пока в статье речь шла о «проекте по наведению порядка на складе». если я решаю наводить порядок около дома — это не значит, что где-то там ходит вредитель, который умышленно мусорит и гадит (хотя, конечно, такое тоже исключать нельзя), а скорее всего люди «просто так» бросают мусор, а после — «по закону разбитых окон» — начинают бросать его еще больше…
                                                      0
                                                      Кагбэ из этого:
                                                      — Итак, ситуация. – начал Сергей. – У нас несколько пользователей, бухгалтеров. У всех – полные права. И кто-то из них, вероятно, нам гадит в учете. Что делать?


                                                      — За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.


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


                                                      Вы текст читали или только коменты?

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

                                                        0
                                                        Естественно, это дыра. точнее, даже не дыра как таковая, а отсутсвие преграды (того, в чем обычно дыра) вообще…
                                                        но это совершенно не означает, что «гадящий в учете» — саботажник, что он вообще действует намеренно и целенаправленно, а не решает "[интеллектуально] доступным ему способом" свои локальные проблемы.
                                                        как пример, в 2004 году сталкивался с тем, что «девочка», начислявшая зарплату, «чтоб не делать каждый раз новый документ», просто меняла дату у документа предыдущего месяца… она была не вредитель, а просто мелкая дура…
                                                          0
                                                          Ошибочные действия без злого умысла тоже вероятны, но с низким процентом. Если вкратце — действия по дурости не могут продолжаться долго, как и хулиганские. «Девочка-дура» — она дура сразу по всем направлениям и вскроется на чем то очень быстро. К тому же, завскладом — это ответственная и хлопотная должность, дур туда не назначают, обычно. Хотя не исключено.

                                                          Самая вероятная версия — хищения. Ее и будут разрабатывать безопасники, причем не только анализом сетевой деятельности. Может статься, что у них уже есть на примете подозрительная кладовщица, но без доказательств.
                                                            0
                                                            еще раз объясняю: действия не «по дурости», а 1)нормальные действия, но несвоевременные. например, ввод/исправление складских документов сильно задним числом. накопили исправлений за месяц, и вводят в начале следующего при закрытии месяца. с точки зрения бухгалтера это нормально — у нее «все идет». Она привела взаиморасчеты «в соответствие с документами»; 2) действия, направленные на «налоговую оптимизацию» (внутрифирменные продажи, перенос дат поступления для налоговых вычетов). 3)Товары в пути оформляются как «поступившие датой документа». 4)человеческие ошибки 5)человеческие решения (ага, взять вот этот припой потому, что он ближе лежит)
                                                            Это бардак, но без хищений. хотя хищения тоже более чем возможны, особенно при бардачном учете (но они чаще следствие бардака)

                                                +1
                                                Интересно, в какой серии появится формулировка — расхождение модели в информационной системе и реальности.
                                                Дальше будут качели — изменения в модели и реальности. Реальность сложна, попытка в лоб привести реальность к модели — приводит к росту бюрократизации и в конце концов проваливается из-за слишком больших накладных расходов на внесение данных в информационную систему. Попытка отразить реальность в модели — ведет к усложнению модели до полной неприменимости. Но каждая итерация порождает островки равновесия между сложностью модели и формализации реальности. Типа производственных линий и конвейеров, автоматизированных складов (Амазон и последователи), CRM, ERP и автоматизации бухгалтерии.

                                                Если говорить конкретно о примере в серии статей, то одним из решений проблемы склада будет выделение части номенклатуры в склад особого учета с задроченными до состояния биороботов работниками (ну или с частичной или полной автоматизацией) и усложненной моделью в информационной системе. Естественно, внедрение и эксплуатация такого склада будет дороже обычного склада, поэтому предварительно надо будет произвести расчет расходов и издержек и уже их сравнить с ожидаемым повышением прибыли. Вполне может оказаться, что это решение экономически невыгодно в момент оценки и бардак останется нетронутым. Перерасчет решения можно производить периодически и/или при появлении/изменении существенных факторов (ну например появление в продаже роботизинованных складов с подходящими параметрами единиц хранения — веса и размера).
                                                  0
                                                  Забавный рассказик, но не более. Зачем программистскими штуками ловить бухгалтера? В любой нормальной системе пишется физически в документах, а не в логах, кто и когда создал документ и дату проводки документа. Если есть проблема, Гл.Бух её враз находит. Найденный документ или период в котором ошибка (но она не локализованна) позволит легко выйти на конкретного пользователя и время выполнения косячной операции. Тут не от полномочий плясать надо. От того кто выявил ошибку и каким путем.
                                                    0
                                                    «враз» найти не так-то просто.
                                                    ну и золотое правило: проблему лучше предотвращать, чем решать.
                                                    поэтому все эти «даты запрета редактирования», «права на доступ в закрытые периодв», «отчеты по изменениям за период», «сравнения версий» и т.п. — они сильно упрощают жизнь и главбухам, и ИТ-шникам.

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

                                                  Самое читаемое