Организация эффективной системы внутреннего контроля на базе платформы 1С. Опыт PwC

а перед этим

Вы как-то определитесь.

А вообще странный вывод платформе, средстве разработке.

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

Ну такую статью я просто обязан немножко потроллить.

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

В 1С на уровне платформы реализована система прав и ролей. Мы можем управлять этими элементами, создавать новые, назначать их пользователям – это все замечательно существует.
Существует отдельное право «Администрирование приложений 1С», можно дать эту роль администратору, которому будет доступна функция, например, добавления пользователей, администрирования приложения. Но при этом он не будет иметь доступа к данным.
Существует возможность ведения лога действий через журнал регистрации.

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

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

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

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

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

Просто ерунда написана. Все эти возможности есть в истории хранилища.

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

Это можно контролировать метками и комментариями в хранилище.

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

Хорошо, что вы предлагаете?

По Бизнес-Процессам забавно читать. Вы какую конфигурацию анализировали? Бухгалтерию 1.6 или 2.0?

Статья написана параноиком о продукте с которым он знаком максимум по слухам!!! :-)

Ребят, я чё то не пойму, вы ж SAP внедряете и рекламируете, что Вам этого мало ? Или клиент настолько измельчал, что денег на SAP и на специалистов по SAP и на консультантов как надо жить в иделолгии SAP уже не хватает ? Вы уж это, определитесь, толи заниматься SAP и пальцы веером, и никаких исправлений задним числом, никаких модификаций в коде, всё только через апрувленные обновления и настройки в рамках системы и мегабабло за консультирование или 1С - твори что хошь, как хошь и вообще полная анархия и беспредел. Корректировки задним числом, изменения кода, поиск багов и создание новых - это всё весело и всё это в 1С норма. Что-то вдруг не работает или работает "не так как ожидалось"? так в этом вся суть 1С - система открыта - бери и разбирайся. Это не ваш глубокозаконспирированный ABAP с 2 миллионами таблиц названных то по немецки то по голандски то по французски да еще и с закрытыми для изменения сценариями.

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

alex_4x, это же аудиторы в первую очередь. Им пофиг, что проверять. У них есть набор метрик и правил, на удовлетворение которым они проверяют систему. Что за система им без разницы (хотя они конечно не скрывают, что метрики разрабатывались под SAP). И поэтому когда им говоришь "это 1С! здесь перепроведение! Какой аудиторский след?" они отвечают "а не колебет"... Вот кстати теперь на инфостарте выступили с этим "а не колебет"...
PS
Три года назад такие вот бравые ребята мне намекали, что пора, пора кому-нибудь оплатить им создания аналога SAPGRCAccesscontrol под 1С. Вот опять намекают :-)

После "риски стали более рискованными" читать не смог. Полная лажа, о чём kser87 уже исчерпывающе отписался.

1. Контроль бизнес справочников - версионирование данных реализовано
2. лог разработки - в хранилище есть история, кто куда что выложил и когда. Согласен, нет статусов готовности/проверенности объекта, но это все можно решить организационно. Среда = копия БД :)
3. Минимальное число ролей - гхгхм, мда,... <нецензура> ... ну откройте посчитаете пальчиком, как только со счета собьётесь, исправьте текст своей статьи

Статья не понравилась, на "выбор экспертов" не тянет, как отмечено в рассылке