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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Поймали?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Это как?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Да так я…

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

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

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

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

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

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

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

— Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— А, ну да…

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

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

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

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

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

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

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

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

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

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

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

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

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

— Так.

— А я пока…

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

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

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

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

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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (46):

  1. Akon32
    /#19104891

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

    Use grep, Luke!


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

    • nmivan
      /#19104955

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

    • vesper-bot
      /#19105087

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


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

      • Akon32
        /#19109213

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

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


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


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

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


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

        • vesper-bot
          /#19113157

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

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


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

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


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

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

  2. Eldhenn
    /#19105049

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

    • AlexTOPMAN
      /#19110887

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

  3. iit
    /#19105215 / +1

    Ура, прода!

  4. tvr
    /#19105253 / +1

    Права дать и индивидуальные пароли для записи новых/изменения старых документов.
    Вылазит косяк с какой-нибудь единицей хранения/учёта — смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период. Когда и если источник проблем будет локализован, показательный расстрел и изъятие лишних прав у остальных. Всё на правах ИМХО.
    P.S. За цикл статей спасибо, хорошо написано.

    • Mike_soft
      /#19105733

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

      • tvr
        /#19105949

        Не, нам же надо отловить, кто через дыру в заборе шастает туда-сюда, а потом уже зададим вопрос отловленным — «А с какой целью, товарищ, вы мимо проходной тропу протоптали?», а вы предлагаете на этой дыре ещё одну проходную поставить поставить.

        • Mike_soft
          /#19106053

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

    • stanislavkulikov
      /#19106295

      А зачем здесь первый пункт с изменением прав?

      смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период

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

  5. stanislavkulikov
    /#19105811 / +2

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

    • fouxer
      /#19106225

      Как я понял, сейчас там нет вообще никакого разделения прав

      • stanislavkulikov
        /#19106339

        Нет разделение прав есть, судя по фразам

        Есть дыра – полные права у всех.

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

        Т.е. просто у всех root права
        Насколько я понял нет нормального аудита и его отсутствие хотят заменить точечными правами. Например, проблема с документом 5X-18, а к этому документу имеет права доступа только Катя, значит она и косячит.
        В общем, самый что ни на есть костыльный способ решения проблемы.

        • jaddd
          /#19109975

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

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

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

  6. evmnn
    /#19106229

    Подозреваю «дырка в заборе» — это Стас, который бухгалтерам и кладовщикам меняет данные задним числом, потому что «нада».

    • imanushin
      /#19106289

      меняет данные задним числом


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

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

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

      Отсутствие аудита и истории изменений — вот это плохо.

      • Mike_soft
        /#19106367

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

        • tvr
          /#19106385

          Удваиваю. Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.

          • Eldhenn
            /#19106511

            Вообще-то в нормальной бухгалтерии так и делается, и делалось всегда до компьютеров.

          • imanushin
            /#19107209

            Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.

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


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


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

            • Mike_soft
              /#19108919

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

              • imanushin
                /#19109815

                Расследование проведено? Ошибка устранена? Товар продан? Если так, то зачем мешать работать? Или вдруг менеджер не знает про строгость бухгалтерской отчетности?

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

            • Akon32
              /#19109105

              git позволяет изменять историю.

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

              • Eldhenn
                /#19109865

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

  7. pnetmon
    /#19106357 / +2

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

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

    • Mike_soft
      /#19108879

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

      • pnetmon
        /#19108923

        фиксировать критичные остатки в той же базе

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


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


        Желание


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

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

        • Mike_soft
          /#19108951

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

        • pnetmon
          /#19109009

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


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


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

          • Mike_soft
            /#19109123

            абсолютно согласен. в этом случае сравнение с сохраненными остатками позволяет вычислить факт правки данных. был случай — штатный программист правил данные прямо в БД по своим обедам (стоимость обедов вычиталась из зарплаты)…

    • alfaterra
      /#19108899

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

      • zxweed
        /#19109571

        а потом ларек с шавермой перенесли в другое место и сетка дорожек на следующий год совершенно другая стала…

        • alfaterra
          /#19110859

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

  8. BlessYourHeart
    /#19107555

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

  9. andyudol
    /#19109153

    Полные права у всех — это не дыра в заборе. Это отсутствие забора.

  10. leossnet
    /#19109765

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

  11. iig
    /#19109843

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

  12. kuzemchik
    /#19111845

    nmivan «Двое парней делали диломный проект, на заводе.» — оч интересно откуда эта история взялась… Потому что она о моем отце.

    • nmivan
      /#19111879

      Город, ВУЗ, факультет, кафедру, фамилию преподавателя знаете?

      • kuzemchik
        /#19112157

        Томск, ТПУ, Электроники (или Электротехники, уточню у него). Последние 3 надо уточнить.
        Завод ЗСМК. Тема диплома что-то связанное электронным реле, но я точно не помню.

        • nmivan
          /#19114375

          нет, это не о вашем отце.
          Совпало просто.

          • kuzemchik
            /#19114377

            Забавно, что даже оценка совпала)

  13. var
    /#19115619

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