@gergerov

Что такое справочник в ИС и какой доступ необходимо организовывать к ним?

Столкнулся с проблемой на работе. В общем очень интересная тема. Как-то кто-то сказал (приказал), что справочники должны управляться отдельным доступом (АРМом). Всё бы ничего, но в ИС 50 АРМов и примерно 150 справочных модулей и некоторый диапазон АРМов должны иметь доступ к редактированию справочников (конкретно: клиенты, грузы, получатели, доверенности, доверенные лица, агенты ну и что-то и т.д.). Если отнять у них доступ и если придет клиент и захочет услугу, то человек с отдельным доступом может отсутствовать, а если будет присутствовать, то услуга превратится в видео с тем ленивцем. С другой стороны, если дать доступ тем, кто работает с клиентами (такой отдельный АРМ), то они смогут крутить системой какой хотят (много справочников). В связи с этим у меня к сообществу хабра вопрос, а как такое разруливать? Как бы общался с теми, от кого это исходит, объяснение: справочник клиентов вовсе не справочник, справочник товаров/грузов вовсе не справочник. Смотрю официальную документацию 1C, а там совсем д...
А именно, справочником может являться '...список сотрудников, перечень товаров, список поставщиков или покупателей...'. В общем диссонанс. Это не трудно переименовать, но всё равно принцип: а что есть справочник? Это ребята из 1C опечатку допустили? Или предприятие чудит?

Что есть справочник в ИС? Какие критерии?
  • Вопрос задан
  • 424 просмотра
Пригласить эксперта
Ответы на вопрос 2
Что есть справочник в ИС?

(В моём понимании. Моё понимание не совпадает с пониманием 1С)
Справочником, как правило, считают данные, которые не имеют бизнес-ценности сами по себе, редко добавляются новые записи, очень редко меняются уже занесённые - короче очень статичные.

Например справочником будет:
Список адресов по ФИАС.
Города и страны.
Единицы измерений.

И так далее.

Тоесть список клиентов, грузов, получателей и так далее - это не справочники. Это полноценные бизнес-данные.

Или предприятие чудит?

Я думаю, что так.

Смотрим на требование, которое вам дало руководство и попробуем его деконструировать:

В общем очень интересная тема. Как-то кто-то сказал (приказал), что справочники должны управляться отдельным доступом (АРМом). Всё бы ничего, но в ИС 50 АРМов и примерно 150 справочных модулей и некоторый диапазон АРМов должны иметь доступ к редактированию справочников (конкретно: клиенты, грузы, получатели, доверенности, доверенные лица, агенты ну и что-то и т.д.

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

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

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

Правильным решением будет:
1. Проанализировать бизнес-процесс и понять кто и какие действия вообще делает.
2. Изменить логику работы ИС так, чтобы она способствовала работе в рамках этого бизнес-процесса.

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

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

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

2. Менеджер
- Вводит в номенклатуру новые товары
- Выводит из номенклатуры товары, которые больше не продаются
- Читает номенклатуру, чтобы иметь возможность понять, что какой-то товар ещё не заведён, или что какой-то товар требуется вывести из оборота.

3. Курьер
- Читает адрес доставки и машино-места заказа, который ему назначен
- Сообщает, что этот заказ был доставлен
- Сообщает, что не удалось этот заказ доставить
- Сообщает, что клиент отказался от товара
- Сообщает, что клиент отказался от заказа целиком

И вот нужно ввести в ИС "процедуры" для всех эти операций и ограничивать доступ на уровне этих процедур.
Прямого доступа к данным не должно быть ни у кого.
(Иначе зачем вам 1С? Если вам допустим полный доступ к данным - вам достаточно будет табличек в условном google docs)
Ответ написан
Комментировать
@rPman
Справочник - это понятие относительное, определяет вид отношений одного типа данных к другим.

Для человека справочником будет например его пол, адрес (если он не в виде строки а полноценная многоуровневая структура) и т.п.

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

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

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

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

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

Войдите, чтобы написать ответ

Похожие вопросы