Жол деңгейіндегі қауіпсіздік (RLS) есептерде: филиалдар мен менеджерлер бойынша қолжетімділік

Міндетті қарапайым тілмен: бір есеп — әр түрлі деректер

Кейде бір есеп барлыққа ортақ болады, бірақ әр адам үшін әртүрлі нәрсе көрсетуі тиіс. Филиал басшысы тек өз филиалын көреді, менеджер — тек өз клиенттері мен сатуларын, ал бас офис — жалпы көріністі. Міне, есептердегі жол деңгейіндегі қауіпсіздік (Row-level security): есеп ашылған адамға байланысты жолдардың көрінуі.

Ең жиі кездесетін «шол» — витриналарды, есептерді немесе беттерді көшіру: «Алматы үшін есеп», «Астана үшін есеп», «әр менеджерге жеке есеп». Бастында ыңғайлы көрінуі мүмкін, бірақ өте тез хаос басталады. Көрсеткіштер өзгерсе, жаңа өрістер қосылса, формулалар түзелсе — сізге бұл өзгерістерді ондаған көшірмеде қайталау керек болады. Нәтижесінде нұсқалар әртүрлі бола бастайды, сандар сәйкес келмейді, ал қолдау тоқтаусыз күреске айналады.

Бұл тек ыңғайсыздық қана емес. Егер қолжетімділік «ауызша» шектелсе (мысалы, беттің сүзгісімен немесе бөлек выгрузкамен), деректер қате адамдарға көрсетілуі мүмкін. Бұл басқалардың филиалының кірісі, жалақы деректері, маржиналдық немесе жоспарлар болуы мүмкін. Соңында — утечкалар, түрлі сандарға байланысты даулар және есепке сенімнің төмендеуі.

Көп жағдайда компанияға бірнеше түсінікті рөл жеткілікті, олар кейін BI-дегі рөлдерге айналады:

• филиал қызметкері — тек өз филиалын немесе учаскесін көреді;
• менеджер — тек «өзінің» клиенттері, мәмілелері, жоспарлары;
• жетекші — командасының бәрін көреді (мысалы, филиал менеджерлері);
• HQ (бас офис) — барлық филиалдар мен жалпы нәтижені көреді.

Жақсы мақсат — бір есеп, бір модель, біртекті метрикалар және шектеулер деректердің өзінде енгізілген — көшірмелерде емес. Сонда көрсеткіш бір рет өзгертілсе, бәріне бірдей дұрыс есептеледі, бірақ әр адам тек өзіне тиесілісін ғана көреді.

Қайдан бастау: көріну ережелері және қолжетімділік деңгейлері

Есептердегі RLS BI баптауларынан емес, келісімнен басталады: қандай деректер сезімтал есептеледі және кімге олар шынымен қажет. Осы қадамды өткізіп жіберсеңіз, не «бәріне бәрі көрініп қалады», не «ешкім жұмыс істей алмайды» деген нәтиже болуы мүмкін.

Алдымен не жасыратынын тізіп шығыңыз. Көбінесе бұл тек сатулар емес, маржа, жеңілдіктер, клиенттер тізімі, шарттар және жеке деректер болады. Жазбаларды (жолдарды) ғана жасырасыз ба, әлде жазба ішіндегі мәліметтерді де жасырасыз ба — бұл нүктені алдын ала анықтау маңызды. Мысалы: филиал бойынша сатуларды көрсету, бірақ клиенттің ТАҚИП-ын көрсетпеу.

Келесі кезең — қолжетімділік деңгейлері мен олардың мәнін анықтау. Көбіне 3-4 деңгей жеткілікті: филиал, өңір, команда және нақты менеджер. Бір адам бірнеше ережеге бір уақытта кіріп қалуы мүмкін — бұл қалыпты: менеджер өз портфелін, ал жетекші командасын көреді.

Ережелерді техникалық емес, қарапайым сөйлемдермен бекітіңіз. Мысалы:

• менеджер тек өз мәмілелері мен клиенттерін көреді;
• команда жетекшісі өзінің командасына қатысты барлығын көреді;
• өңірлік жетекші аймағының филиалдарын көреді;
• бэк-офис барлықын көреді, бірақ жеке деректерсіз;
• қаржы бөлімі маржа мен жеңілдіктерді көреді, басқалар тек табысты көреді.

Ерекшеліктерді бөлек тіркеңіз, әйтпесе олар модельді ең нашар сәтте «бұзады». Типтік жағдайлар: уақытша алмастыру (демалыс), бірлескен мәмілелер (екі менеджер), матрицалық басқару (функционалдық жетекші), басшыларға толық шолу қажет болуы.

Соңында жолдарды шектеу мен детализацияны шектеу арасындағы шекараны анықтаңыз. RLS «қандай жазбалар көрінеді» дегенге жауап береді, бірақ кейде рұқсат етілген жолдардың ішінде өрістерді немесе көрсеткіштерді жасыру қажет болады (мысалы, маржа). Бұл мәселені алдын ала келісіп қойған жөн, әйтпесе кейін «барлығына көрсетіңіз, бірақ маржаны және клиенттерді алып тастаңыз» деген сұранысты қайта құру қажет болады.

Модельді қалай құру керек, RLS дұрыс жұмыс істесін

RLS сенімді жұмыс істеуі үшін ролдерден емес, модельден бастаңыз. RLS әдетте формуладан емес, филиал немесе менеджер фактілерде әр түрлі сақталатындықтан, байланыстар шатасқандықтан және кілттер сәйкес келмегендіктен бұзылады.

Негіз — жеке справочниктер. "Филиалдар" және "Менеджерлер" өлшем кестелерін жасаңыз, ал сатулар, жоспарлар, өтініштер сияқты оқиғаларды факт ретінде ұстаңыз. Справочниктерде тұрақты идентификаторлар мен атрибуттарды (атауы, өңірі, статусы) сақтаңыз, бірақ пайдаланушыны емес.

Келесі маңызды жайт — сүзгінің фактілерге қалай жететіні. Егер факт жолында BranchID бар болса, онда "Филиалдар -> Факт" қатынасы бір-бірден-көп болу керек және айқын болуы тиіс. Егер филиал дүкен, бөлім немесе жоба арқылы анықталса, аралық өлшем қосып, біртекті маршрут ұсыныңыз. Әйтпесе RLS әртүрлі визуализацияларда әртүрлі нәтижелер береді.

"Пайдаланушы -> қолжетімділік" сәйкестендіру кестесін әдетте бөлек байланыстырушы (bridge) кестесі етіп жасайды. Ол жерде әр жол — пайдаланушы мен қолжетімді объект: филиал және қажет болса менеджер. Бір жетекшіге 3 филиал берілген болса — оған 3 жол болады. Менеджер бірнеше филиалда жұмыс істесе — бұл да жолдар арқылы шешіледі, витриналарды көшіру емес.

Нысандар үшін кілт біреу және "таза" болуы тиіс. Филиал пен қызметкер үшін ішкі ID (нөмір немесе UUID) пайдаланыңыз, атауын емес. Пайдаланушыға BI-ге кіру кезінде шынымен келетін идентификаторды (логин немесе UPN) пайдаланыңыз және бәрінде бір форматта сақтаңыз.

Агрегаттар мен жиынтықтарды сүзгіден кейін бұзбау үшін негізгі заттарды тексеріңіз:

• справочниктерден келген сүзгілер фактілерге бір маршрутпен жетуі тиіс, екіұдай байланыстарсыз;
• көп-көп қатынастар қажет жерде bridge-таблица қолданылсын;
• жиынтықтар фактілер бойынша есептелсін, справочниктер бойынша емес (әйтпесе "бос" филиалдар оғаш мінездеме береді);
• "барлық филиалдар" құқықты бөлек роль ретінде жасамаңыз — оны матрица арқылы басқарыңыз.

Практикада бұл былай көрінеді: "Сатулар" кестесі BranchID және ManagerID ұстайды, "Филиалдар" мен "Менеджерлер" онымен байланысады, ал "Құқықтар" пайдаланушыны рұқсат етілген BranchID және ManagerID-ге байланыстырады. Содан кейін RLS қарапайым: ағымдағы пайдаланушы бойынша "Құқықтар" шектеледі және сүзгі факттерге өз-өзінен жетеді, жалпы сомаларды бұзбай.

Статикалық және динамикалық RLS: қайсысын таңдау

Есептердегі RLS-ті екі негізгі жолмен орнатуға болады: статикалық (бекітілген рөлдер) немесе динамикалық (құқықтар пайдаланушыға байланысты өзгереді). Екі әдіс те адамдарға өз филиалдарын, командаларын немесе клиенттерін ғана көрсетеді. Айырмашылық — қанша қолмен жұмысты кейін жүргізуге тура келеді.

Статикалық RLS: бастау оңай, өсу қиынырақ

Статикалық рөлдер тұрақты құрылым және аз варианттар болғанда жарайды. Мысалы, 5-10 филиал бар, өзгерістер сирек, пайдаланушылар аз.

Бұл тәсілде "Алматы филиалы", "Астана филиалы" сияқты рөлдер жасап, адамдарды сол рөлдерге қолмен қосасыз. Бизнесті түсіндіру оңай және пилотты жылдам іске қосуға болады.

Минустары кейін көрінеді: менеджер ауысса, жаңа филиал ашылса немесе демалысқа шықса — рөлдерді қолмен өңдеу толассыз ағымға айналады. Рөлдер ұсақталғанда: "Алматы — жетекшілер", "Алматы — сатушылар" сияқты, қолдау күрделенеді.

Динамикалық RLS: қолмен жұмысты азайтады, тәртіпті арттырады

Динамикалық RLS пайдаланушылар көп және өзгерістер жиі болса қолайлы. Онда онсыз да рөлдер көп емес, бір-екі рөл жасап, қолжетімділікті деректердегі құқықтар кестесіне байланыстырасыз.

Әдетте пайдаланушы корпоративті есептік жазбамен кіргенде, BI оның логинін (немесе e-mail) алып, құқықтар кестесінен іздейді. Табылған жолдар арқылы филиалдар мен деректер сүзгіленеді.

Корпоративті топтарды (мысалы, сату бөлімі, өңірлік командалар) пайдалану арқылы құқықтарды ИТ немесе HR-ге тапсыруға болады. Адамды басқа бөлімге ауыстырса — топ жаңартылады және құқық автоматты түрде өзгереді, есепті қайта конфигурациялау қажет болмайды.

Құқықтар кестесі бақылауға да ыңғайлы: матрицаны ашып, кімде қандай құқық бар екенін бірден көруге болады.

Мысалы: менеджер Иван бүгін филиал А мен Б-ға жауапты, ал ертең тек Б. Статикалық рөлдерде әкімші рөлдерді өзгертеді. Динамикалықта матрицадағы жолды өзгерту жеткілікті — оған сүйенген барлық есептер автоматты түрде дұрыс көрсетеді.

Қайсысын таңдардан бұрын сұрақтарға жауап беріңіз:

• бір жылдан кейін қанша филиал және пайдаланушы болады;
• жауапкершілік ауысуы қаншалықты жиі болады;
• уақытша құқықтар (алмастыру, жобалар, іссапар) қажет пе;
• құқықтарды кім және қандай негізде ашқанын тексеру қажет пе.

Өсу мен жиі өзгерістер болса — бастапқыдан динамикалық RLS және құқықтар матрицасын жоспарлаған дұрыс.

Қадам-қадам: филиалдар мен менеджерлер бойынша шектеуді қалай орнату

RLS есептерде витриналарды көшірусіз жұмыс істеуі үшін BI ішіндегі батырмалардан емес, ережелерден бастаңыз: кім не көруі тиіс және қандай жағдайларда қолжетімділік кеңейеді (мысалы, уақытша алмастыру).

1) Рөлдер мен көріну деңгейлерін бекітіңіз

2-3 рөлді адам тілімен сипаттап, оларды деректер деңгейлеріне байлаңыз. Көбінесе: қызметкер тек өз филиалын, менеджер — клиенттер тізімін немесе өзінің жоспарын, жетекші — команданы немесе өңірді көреді. Даулы жерлерді бірден шешіңіз: менеджер басқа менеджерлердің жоспарларын көре ме, жетекші жеке көрсеткіштерді көреді ме, бірлескен сатулар қалай өңделеді.

2) Құқықтар кестесін (матрица) дайындаңыз

Бір ғана құқықтар көзі болсын, әр жол — бір рұқсат. "Әр филиалға баған" сияқты форматтан қашыңыз, "пайдаланушы — қолжетімді объект" тәсілін қолданыңыз. Міндетті өрістер:

• логин (BI-ге кірген кезде келетін формат);
• қол жеткізу түрі (филиал, менеджер, өңір);
• филиал коды немесе менеджер ID (фактілердегі сол кілттер);
• басталу және аяқталу датасы (қажет болса);
• ескерту немесе өзгертуді тіркеген адам (дауларды шешу үшін).

3) Құқықтар кестесін модельге жалғаңыз

Модельде бұл кесте фактілер сүзгіленетін сол справочниктерге қосылуы керек: филиалдар, қызметкерлер, менеджерлер. Негізгі ереже: сүзгі сатуларға, жоспарларға және басқа көрсеткіштерге әдеттегі байланыстар арқылы жетуі тиіс. Байланыстар «шатыспауы» маңызды; әйтпесе RLS күтпеген орындарда тесік береді.

4) Сүзгі ережесін баптап, тесттік аккаунттарда тексеріңіз

Роль жасаңыз және шарт қойыңыз: ағымдағы пайдаланушының логині құқықтар кестесіндегі логинге тең болған жағдайда жолдарды көрсету. Содан кейін минимум үш сценарий тексеріңіз: бір филиал қызметкері, екі филиалға қолжетімді менеджер, өңір жетекшісі. Тестілеу барысында тек сомаларды ғана емес, детализацияны, кестелер мен экспортты да қарастырыңыз.

5) Құқықтарды жаңарту процесін бекітіңіз

Тіпті идеалды баптау да, құқықты кім өзгертетінін анықтамаса, ыдырайды. Құқықтар матрицасының иесін белгілеңіз (әдетте HR, қауіпсіздік немесе сату бөлімінің әкімшісі) және қарапайым регламент жасаңыз: жаңа қызметкерді қалай қосамыз, жұмыстан кеткен кезде қалай өшіреміз, уақытша кеңейтуді қалай рәсімдейміз.

Мысал: менеджер A филиал 01 және 02-ны басқарады, менеджер B тек 03-ті. Матрицада бұл үш жол ретінде көрінеді, витринадтар көшірілмейді. Екі адам бір есепті көреді, бірақ сандар әртүрлі — себебі сүзгі филиал справочнигі арқылы фактілерге жетеді.

Құқықтар матрицасын қайда сақтау және қалай жаңарту

Құқықтар матрицасы — қай пайдаланушы қандай жолды көре алатынын анықтайтын кесте. RLS үшін маңыздысы — бұл кесте біртұтас құқықтар көзі болуы тиіс, әр түрлі витриналарда шашылатын ережелер жиынтығы емес.

Матрицаның ең сенімді көзі — операциялық жүйелер: HR (штат, орг құрылымы, жетекшілер) және CRM (клиенттерге бекіту, өңірлер, менеджерлер). Егер менеджер тағайындаулары CRM-де болса — сол жерден алыңыз. Егер филиал мен лауазым HR-де тұрса — HR-дан алыңыз. Негізгі қағида — Excel-дерде жеке «справочниктер» қалыптастырмау.

Матрицада не сақтау керек

Құқықтар түсінікті және тексерілетін болуы үшін минимум өрістер:

• UserID (почта немесе домендік есептік жазба);
• қолжетімділік деңгейі (филиал, өңір, нақты менеджер);
• қолжетімділік кілті (филиал коды немесе менеджер ID);
• басталу және аяқталу датасы (уақытша тағайындаулар үшін);
• көз және себеп (HR, CRM, бұйрық, жоба).

Өзгерістер тарихы — көшу мен ротация проблемаларын шешеді. Менеджер филиалды ауыстырса, ескі жазбаны аяқталу датасымен жабыңыз және жаңасын қосыңыз. Осындай тәсіл өткен кезеңдерге қатысты есептерді дұрыс көрсетуге мүмкіндік береді: ескі құрылымды қолдана ма немесе ағымдағыны — бұл бизнес ережесіне байланысты.

Уақытша құқықтарды рөлдер арқылы емес, мерзімі бар жазбалар арқылы беру ыңғайлы. Мысалы, екі аптаға филиалға қолжетімділік берілді — ол автоматты түрде мерзімі өткеннен кейін жойылады.

Қолмен түзетусіз жаңарту қалай ұйымдастырылады

Автоматтандыру әдетте жүктеуді жоспарлаудан және қарапайым сапа бақылауларынан тұрады:

• HR мен CRM-ден үнемі экспорт (мысалы, тәулігіне бір рет);
• тұрақты кілттер бойынша біріктіру (UserID, филиал кодтары, қызметкер ID);
• қайталануларға, бос кілттерге және басталу датасы жоқ тағайындауларға тексеру;
• өзгерістер журналы (не өзгергенін сақтау);
• аномалия кезде сигнал (менеджерсіз филиал, филиал жетекшісіз).

Практикалық мысал: Иванованы филиал А-дан Б-ға ауыстырды, және өтіп жатқан тапсырма кезеңінде оған екі филиалға қолжетімділік 10 күнге берілді. Матрицада бұл ескі жазбаны аяқтау, жаңа жазба және уақытша жазба ретінде көрінеді. Есептер құқықтарды дұрыс көрсетеді, витриналарды көшірудің қажеті жоқ.

RLS енгізуде жиі жіберілетін қателер мен тұзақтар

RLS формалды дұрыс орнатылса да, проблемалар көбінесе деректер, справочниктер және нақты процесс тоғысында басталады.

1) Пайдаланушы дұрыс сәйкестендірілмеген

Утечка немесе керісінше бос есептердің себебі — пайдаланушы кілті дұрыс емес. Логиндер өзгеруі мүмкін, AD-да қайталану кездеседі, біреу UPN арқылы кірсе, матрицада e-mail тұр. Нәтижесінде бір адам басқа адамның құқықтарын алады, ал тағы бірі өзінікінен айырылады.

Практика: бір тұрақты идентификатор (мысалы, корпоративті UPN) таңдап, бәрінде бірдей пайдаланыңыз: құқықтар матрицасында, пайдаланушылар кестесінде және RLS ережесінде.

2) Фактілерде филиал жоқ немесе ол бос

Көп жағдайда рөлдер филиалға негізделеді, бірақ сатулар кестесінде "Филиал" өрісі әр жол үшін толтырылмаған. Сол кезде сүзгі жұмыс істемейді: артық деректер көрсетілуі немесе ештеңе көрсетілмеуі мүмкін.

Орындау алдында тексеріңіз:

• фактілерде әр жолда филиал кілті бар ма;
• "бос" филиал жолдары жоқ па;
• филиал кодтары факттер мен справочникте сәйкес келетін бе;
• атаулар мен кодтардың араласпауы ("Алматы" vs "ALM");
• біртұтас филиал справочнигі бар ма.

3) Рөлдерді араластыру және күтпеген "құқықтардың жиынтығы"

Әкімшілік өмірі "бір адам — бір филиал" схемасынан күрделірек болады. Бір адам бірнеше рөлге түсіп қалса, ол барлық рұқсаттардың қосындысын көреді. Кейде бұл дұрыс, кейде — емес.

Шатастырмау үшін рөлдерді қолмен көбейтпеңіз. "Пайдаланушы — объект" матрицасын сақтаңыз және ережені бір сөйлеммен түсіндіруге болатын етіп жасаңыз. Даулы жағдайларда қолжетімділік түрін көрсетіңіз (мысалы, "тек өз филиалы" немесе "тізім бойынша") және кім мұндай құқықтарды беретінін бекітіңіз.

4) Экспорт пен детализация арқылы шектеуді айналып өту

RLS графиктерде ғана емес, басқа мүмкіндіктерде де жұмыс істеуі тиіс. Пайдаланушы экспорт арқылы немесе "кесте ретінде көру", детализация арқылы артық деректер алмайтынын тексеріңіз. Бұл әсіресе жеке жоспарлар мен KPI бар жерлерде маңызды.

5) Кім түсінбейтін тым күрделі ережелер

Ереже "сиқыршылардың" жұмысы сияқты күрделі болса және бір адамға ғана байланысты болса, реорганизацияда бәрі бірден бұзылады. Қарапайым матрица мен түсінікті ережелер көп жағдайда хитрый ерекшеліктерден жақсы.

Ереже: келесі күні жетекшілер мен аймақтар өзгерсе, сіз матрицаны жолдарды ауыстыру арқылы жаңартуыңыз керек, формулалар мен рөлдерді қайта жазу емес.

RLS дұрыс жұмыс істеп тұрғанын қалай тексеру

Тексеру бір қарапайым сұраққа жауап береді: бір есеп әртүрлі пайдаланушыларға әртүрлі деректер көрсетеді және сандар дұрыс есептеледі ме. Қателік жиі жиынтықтарда, сүзгілерде және «ерекше» пайдаланушыларда шығады.

Бастаңыз 3-5 тесттік пайдаланушыдан, әр түрлі рөлдерді көрсететін: филиал менеджері, филиал жетекшісі, өңір жетекшісі, бэк-офис қызметкері (бірнеше филиалды көреді), әкімші (бәрін көреді). Тексеру үшін бөлек тесттік аккаунттар жасаған ыңғайлы — модельді өзгерткеннен кейін тексерулерді қайталау оңай болады.

Міндетті тексерулер жиынтығы

Бірдей беттер мен визуализацияларды әр пайдаланушыда қолданып тексеріңіз:

• жолдардың көрінуі (детальды кесте): "басқа" филиалдар мен менеджерлер еш жерде шықпау тиіс, сұрыптауда да, іздеуде де;
• жиынтықтар мен аралық жиынтықтар: сомалар тек рұқсат етілген деректер бойынша есептелуі тиіс, жасырын жолдар қоспаланбауы керек;
• сүзгілер мен слайсерлер: пайдаланушы тыйым салынған филиалды сүзгіден таба алмауы тиіс;
• экспорт пен детализация: экспортталған және drill-through арқылы алынған деректер де сол шектеулерге бағынуы керек;
• бос нәтиже: пайдаланушының рұқсаты жоқ болса, есеп дұрыс түрде "бос" көрсетуі тиіс (қате немесе "бәрі деректер" көрсетпеу).

Содан кейін бақылау сандарымен сәйкестендіріңіз. Бұл белгілі бір филиалға және кезеңге қатысты сенімді мәндер: табыс, тапсырыстар саны, жоспар, маржа. Бақылау мәндерін сенімді дереккөзден (мысалы, бухгалтерияның немесе жабық реестрдің экспортынан) алыңыз.

Ерекшеліктерді бөлек тексеріңіз: өңір жетекшісі өз өңірінің барлық филиалдарын көреді ме, уақытша алмастыру тек мерзімге шектелген бе, қосымша рөлдер қате филиалдарды ашпай ма. Нақты өмірде дәл осы ерекшеліктер ең жиі қателік тудырады.

Тесті бір реттікке қалдырмау үшін сценарийлерді бекітіңіз: кім тексерілетін, қандай беттер, қандай сүзгілер, қандай бақылау сандар және күтілетін нәтиже. Осылайша релиз алдында тексеруді 10-15 минут ішінде қайталауға болады.

Мысал: бөлшек сауда желісі — филиалдар мен жеке жоспарлар

8 филиалы бар бөлшек сауда желісін елестетейік. Бір есеп сатулар мен жоспарлар үшін бар, бірақ әр адамға деректер әртүрлі көрсетілуі тиіс. Мұнда есептердегі жол деңгейіндегі қауіпсіздік жақсы жұмыс істейді: бір деректер жиынтығы, ал көріну ережелер арқылы қысқарады.

Дүкен менеджері есепті ашқанда тек өз мәмілелерін, өз табысын және өз жоспарын көреді. Ол өткен аймен салыстырады, бірақ басқа менеджерлерді көрмейді, тіпті сол филиалда болса да. Филиал директорлары барлық менеджерлерді көреді, өңірлік жетекші — өз өңірінің филиалдары, бас офис — барлық желіні.

Бұл көшіріліп жасалатын витриналарсыз жұмыс істеуі үшін модельде факттар (сатулар, жоспарлар, қайтарулар), справочниктер (филиалдар, өңірлер, менеджерлер) және құқықтар кестесі (кімге не рұқсат) айқын бөлінеді.

Күрделі жағдай: бір клиент екі филиалдан қызмет алады. Мысалы, корпоративтік клиент A филиалына сатып алады, бірақ кейде жеткізу B филиалы арқылы жүреді. Мұнда екі вариантың бар.

Бірінші: сатуларды жеткізу филиалына байланыстырып, клиентке екі филиалға да қолжетімділік беру үшін бөлек "клиент — филиал" кестесін қосу.

Екінші: "клиенттің негізгі филиалы" ережесін енгізіп, мұндай сатуларды тек негізгі командаға көрсету; екінші филиалға тек агрегат түрінде рұқсат беру (менеджер деталдарысыз).

Таңдау компанияның жауапкершілік пен бонустар жүйесіне байланысты.

Тағы бір өмірлік жағдай: менеджерді басқа филиалға ауыстырады. Идеалда матрицада тағайындау ғана өзгереді (және қажет болса басталу датасы). Содан кейін есепте ол жаңа деректерді дереу көреді. Тарихты қалай көрсету керек — бұрынғы сатуларды көрсету керек пе деген сұрақ — алдын ала ережемен шешілуі тиіс: "ағымдағы филиал бойынша көру" немесе "сатылым кезіндегі филиал бойынша көру".

Кез-келген жағдайда кеңес жиыны үшін жалпы есеп, бірақ жеке деталдарсыз қажет болуы мүмкін. Сонда басқа бетті немесе визуализация жиынтығын жасап, деректерді филиал/өңір деңгейіне агрегаттап, менеджер өрістерін жасырады.

Чек-лист және іске асыруға келесі қадамдар

Eсептердегі RLS бір рөл баптауында емес, тәртіпте жатыр: түсінікті ережелер, бір құқықтар кестесі және тұрақты тексеру.

Іске қосар алдындағы тез чек-лист

• Модельде факттарды филиал мен менеджерге байланыстыратын айқын кілттер бар (қайталанулар мен сұр зоналар жоқ).
• Құқықтар кестесі бизнес-деректерден бөлек және бақыланатын көздерден жаңартылады.
• Рөлдер тесттік пайдаланушыларда тексерілген: минимум "менеджер", "филиал жетекшісі", "бас офис".
• Теріс тесттер бар: пайдаланушы бөтен филиал мен бөтен жоспарларды көрмейтінін тексеріңіз.
• Есепте модель сүзгілерін айналып өтетін беттер немесе визуализациялар жоқ.

Құқықтар үшін жауапты кім және оларды қалай қолдау

Процестің иесін белгілеңіз. Әдетте бұл BI-разработчик емес, бизнес-роль: мысалы, сату жетекшісі немесе тіркеу әкімшісі. Оның міндеті — кім кімге бағынышты екенін, қандай филиалдарға қолжетімді екенін растау және құқықты уақытында алып тастау.

Одан кейін қарапайым регламент жасаңыз: жаңа қызметкерді қалай қосу, басқа филиалға ауысқанда не істеу, жұмыстан кеткен кезде құқықты дереу өшіру және қаншалықты жиі ревизия жасау (мысалы, айына бір рет).

Егер есептер модель мен ережелер күрделенгендіктен баяуласын десеңіз, шешім әдетте "тағы бір сүзгі қосу" емес, модельді қайта тәртіпке келтіру және инфрақұрылымды күшейту. Үлкен ұйымдарда BI мен деректер сақтау сенімділігін қамтамасыз ету үшін жүйелік интеграция және инфрақұрылымдық шешімдер (мысалы, GSE.kz ұсынатын S200 серверлері, 24/7 қолдау және Қазақстан бойынша сервис желісі) пайдалы болуы мүмкін.

Келесі қадам — тексерістер күнтізбесін енгізіп, бір "контрольдік" тесттік пайдаланушылар тобы жасап алу, сонда кез келген релизді 10-15 минут ішінде жылдам тексеруге болады.