The Workplace and its Collaboration Tools

It’s great to be able to work from anywhere, any device and having the technology work when you need it. More than a luxury, it’s a necessity in the current intensified remote working situation, or for international organisations with very mobile, distributed, fluid users. While so many changes happen during the crisis, your workplace should support your business reconfiguration through enabling staff, partners, suppliers to work with different applications, different teams, etc.

The word “Workplace” used in this context refers to more than the workstations and collaboration tools. It extends to wider areas such as enterprise architecture, application security & identity and access management. Arguably, we’re talking about the wider IT foundation/digital capabilities, to support and enable business needs – the workplace might just be the tip of the iceberg.

Legacy upon Legacy adds Complexity

On the user side, as soon as you go through multiple use-cases, e.g. accessing a legacy system on premise or a Software as a Service application, you are likely to require multiple accounts and therefore a cumbersome user experience.

On the IT operation side, it is equally a burden to make it work: workstations are still most of the time a physical device bound to a rigid corporate domain; they need to be configured, then shipped to remote staff or external parties, and accounts still need to be provisioned in target environments, with access rights set appropriately. All the above usually being different processes which are repeated for each supplier or partner, leading to as many devices and set ups.

More importantly, how secure is this disorganised and overlapping situation? Having visibility and control on who has access to what, end to end and for all environments, is a challenge because of the siloed use-cases. And as users join and leave, applications evolve, the security level likely decreases by lack of keeping accounts and rights accurate.

In our experience at Wavestone, all these challenges stem from the accumulation of new use-cases and technology, implemented in silo, for their own use or limited group of use-cases. The platform, which was first designed with one primary use, has now altered into a manifold use platform with an ill-fitting model and processes. Many organisations today can be proud to rely on a federated platform and modern access experience for cloud applications on one side – and a different, yet reasonably good, experience on internal applications side. However, often both are not integrated and therefore don’t get the benefits we described in the introduction. We believe this comes from the lack of a truly shared model/architecture to support a modern experience, across all use-cases.

.

Figure 1 – Example of a corporate model in which each entity manages identities and their access separately: duplicating processes

One Model for a streamline experience

For this reason and for the future of user experience, at Wavestone we believe in a model based on Identity Control Tower(s).

An Identity Control Tower is a platform to enforce your access policies. Its purpose is to verify access requests coming from trusted sources of identity and determine if that identity is allowed to access a target digital resource. For the metaphor, a pilot willing to get clearance for take-off will submit their flight plan using a trusted channel, and after its approval and other verification by controllers, the pilot can proceed to take-off. If we were to transpose this metaphor digitally, we would talk about a user: in order for said user to access X platform, (s)he would need to use a corporate process which itself is trusted by an Identity Control Tower. Said user would provide their “access plan” (e.g. session token) to the Identity Control Tower. After the Identity Control Tower has verified the authenticity of the “access plan” against its access policies it will perform other checks of context, such as: time of the request, location of origin of the access, trust level of the device etc, the user can then proceed to access the resources. Should these verifications highlight anything unusual or inconsistent in authenticating the user, additional requests can be made to allow the user in (re-authentication or step up).

The Identity Control Tower is under your control and holds the conditions of access i.e. access policies and accepts users from specific sources thanks to a pre-established trust relationship between organisations.

For instance, in the diagram below, imagine a situation in which a supplier is developing a new service in your cloud environment. Users from the supplier would keep their device and authentication process they use within their corporate environment, while the Identity Control Tower (ICT) would enforce access control to the cloud environment – without having to use and manage a different account and re-authenticate. For environments with very granular privileges like AWS, building a decoupled ICT is maybe not a realistic approach and the ICT is then probably the identity platform from Amazon that is managed by your organisation and linked to the identity provider of the supplier. The Identity Control Tower model is basically an extension of federation, implemented to cover all use-cases.

Figure 2 – Access of a Partner user to a Cloud Provider resource through an Identity Control Tower

In another scenario, as seen in this diagram, let’s consider an applicant applying for a job in your organisation, thanks to a recruitment portal you offer. They would initiate an application in your portal using their government-backed digital identity, and once they provide their consent to access their LinkedIn profile, you could obtain a digital CV. For the applicant, it is as simple as showing their ID and giving a copy of their CV, rather than filling-in registration form(s) asking once again for the same standard identity information and risking a typo in their contact details – or even having to send copies of sensitive documents like their passport.

Figure 3 – An alternative scenario presenting the trust relationship between a government ID platform and the corporate

One Model, Three Key Pillars

Using our knowledge and experience, we believe that this model should be built upon three key pillars: a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship.

A Unique Identity Architecture: this is achieved by following a simple rule: don’t duplicate identity data. The less identity records you create for the same physical person, the more streamline the digital experience will be – as cumbersome steps start to appear when an additional account, device or authentication action is required for the user to access the target resource. The key behind a unique identity data is to try reusing the data from its (authoritative) source instead of duplicating/copying it in your own systems. For instance, the suppliers or partners working with your organisation likely already have professional digital identities for their own IT use – what would be the conditions to leverage them instead of re-creating them?[1] The next two pillars contribute to answering this question.

A Common and Flexible Model: The second pillar is to use a common and flexible model to allow/restrict access to information. To provide flexibility, an attribute-based access control (ABAC) model enables granular rules and is well suited to a risk-based and adaptive approach. To make it work though, it is essential to define the “grammar” of the authorisation model: what are the actual attributes used to provide accesses that make sense at the enterprise level? How do they translate into “privileges”? What are their formats/values? When the Identity Control Tower is provided by a cloud provider (e.g. from a Cloud provider as Azure or AWS), the grammar is often determined by the said service. Furthermore, to make this model as widespread as possible across use-cases, both on the identity source side and on providing access on the target service side, we recommend implementing your platform following market standards to maximise inter-operability (SAML, OpenID Connect, OAuth, FIDO, etc.).

360° Trust Relationship: Finally, the last pillar is to ensure the establishment of a 360° Trust Relationship. In other words, perform due diligence and establish confidence thresholds to accept interconnection (“technical trust”) of identity platforms. The due diligence should extend to all upstream processes leading to feeding the platform with identities, for instance the HR/procurement processes to vet identities, up to the IT on-boarding process itself – because trusting an identity platform is a first step for these identities to access your digital resources, you need to be within tolerance of the risk it comes with. This trust relationship should then be implemented through security level expectations, auditability in contractual clauses, and enforced via the supplier service management governance. With such strong requirements, one organisation must be prepared to temporarily on-board suppliers or partners within the organisation’s own platform, while suppliers or partners remediate their processes and platforms to be compliant.

Two key success factors

In order to implement these three key pillars, Wavestone has identified two key success factors: being sponsored by appropriate level of management and building resilience and privacy by design. A transformation programme to establish this model would have implications and requirements in several of your organisation’s departments (HR, sourcing, legal, IT, risk, security etc.), hence should be sponsored by top-management and driven with a pan-organisation approach.
Additionally, as it should always be, the supporting platform should be designed and built with security, privacy and resilience considerations from the beginning.

Final Thoughts

As you have been able to understand throughout this article, looking at the user experience end to end and across use-cases is key to really streamline digital services. This can be achieved with a pan-organisation shift to enforce a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship with third parties.

To go further in your reflection on the subject and understand the current state of your organisation, think about these questions and try to answer them: picking users from different departments, what does the typical day to day digital experience look like? How long does my organisation take to on-board contractors and third parties? How does my organisation actually give access to its data and resources for external users? How many duplicate identities exist across my IT estate?

[1] A technical entry might still exist within your systems, for reference purposes – but from the user perspective there is no new account, no duplicate, if they don’t have to register a new login, credentials etc.

Cet article Key Enablers in Creating a Seamless and Secure User Experience est apparu en premier sur RiskInsight.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot “lieu de travail” utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son “plan d’accès” (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du “plan d’accès” par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la “grammaire” du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en “privilèges” ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (“confiance technique”) des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.

We have cited five key success factors needed to deliver an ERP permissions risk-remediation project:

The key success factors for an ERP permissions risk-remediation project

The first two key success factors were discussed in the previous article; and the other three are covered in this one.

3. Preparing for large-scale deployment

Services, business lines, geographical or legal entities… the remediation of permission-related risks means reviewing user accounts across varied—and often numerous—functional areas. To be able to keep to schedules, limit workloads, and reassure those involved in the project locally, it’s best to deploy things at as larger scale as possible. Doing this means:

• Defining and communicating the risk analysis and remediation methodology;
• Putting in place a steering plan;
• Introducing analytical tools, automated as far as possible, to cope with volumes;
• Formally preparing materials for workshops and consolidation sessions;
• The documentation for the methodology and the tool in order to be able to train users.

These documents will form the deployment kit to be used in the different areas of work of the project phase; this can also continue to be used when the project phase is complete.

The deployment kit for an ERP permissions risk-remediation project

The deployment methodology will need to cover the following activities, and will need to be recreated for each area of work:

• Risk assessments and the definition of KPIs.
• Remediation workshops for user-related risks.
• Validation and execution of remediation plans.
• Training and support for upskilling.

Obviously, the methodology must be adapted to the company’s organizational structure and the resources available to it: the workforce, local variations in business processes, the degree of maturity in risk and permissions management, etc.

In particular, this will involve engaging local experts both on the technical aspects of permissions (access rights officers, application owners, security officers), and on the business-function aspects of processes (business-function representatives, process owners, internal controllers, team managers, etc.). The contribution that will be expected from them, and the effort they will need to put in, should be clear from the start and must remain “reasonable”. Local managers should therefore be involved, to ensure that those who need to take part do so, and to help in decision-making.

During remediation workshops, participants will, in particular, analyze user-related risks, but they will also have to consider various remediation strategies, such as the ones described below:

Strategies to consider in an ERP permissions risk-remediation project

It’s always preferable to validate the methodology using a pilot project that is small enough to limit work volumes, but large enough to be representative of the company. In some cases, a better strategic choice may be to select a work area that’s likely to be more fruitful for the project; or, conversely, one that’s expected to require more support. The lessons learned at the pilot stage will allow the methodology and tools to be adjusted before they are deployed more widely.

4. Selecting the right tools

The tools put in place must aid success during the project phase, but also—and more importantly—provide long-term support for the chosen approach; both these phases must be complementary.

Being well equipped is about being clear on the initial controls to be applied (at the point when new permissions are requested) as well as on the ongoing controls (those applied once permissions have been granted). Having more initial controls will help reduce risks, but operational efficiency may also suffer (delays, difficulties in processing requests, etc.); a balance needs to be found.

From a functional point of view, it’s a question of putting in place the families of controls typically found in such projects, namely:

• Data quality controls: completeness and coherence of data; respect for nomenclature, etc.
• IT security-rule controls: orphan, dormant, and administrator accounts; temporary and residual permissions; IT accounts with business-function permissions and vice versa, etc.
• Business-functions rules/compliance controls: discrepancies between jobs and the associated permissions; discrepancies in permissions between members of the same team; breaches of rules on the segregation of duties; users having access to areas that are beyond the scope of their responsibility, etc.
• Usages and behavior control: excessive or unusual uses, suspicious behavior, typical fraud scenarios, etc.

Families of typical controls for an ERP permissions risk-remediation project

Being well equipped is also about prioritizing and automating the controls that are worth putting in place. The return on investment must be assessed in terms of each control’s relevance to the company’s situation (does the control cost more than dealing with the consequences of the risk it’s designed to cover?), and the potential benefits of automation (how much will be saved compared with a manual process?).

The volumes and complexities associated with ERP authorization models means turning to tools specifically designed for the task: for example, it’s not unusual to see SAP systems with several thousand roles and over a hundred thousand fine-grained permissions (transactions and authorization objects).

These needs fall at the intersection of several different segments of the software market; these are currently highly dynamic and far from mutually exclusive: “Identity and Access Management”, “Continuous Control”, “Specialized Governance-Risk-Compliance tools on a given ERP”, and so on. Given this, the approach taken, degree of maturity, functional coverage, and mode of delivery (on site or cloud/SaaS), can vary substantially from one product to another.

When selecting a tool, it’s a question of considering the following elements carefully:

• Ergonomics and ease of use: once the project is finished, the tool’s users will be mostly from business functions—not from IT.
• Customization options: such that the tool really can be used to support the methodology taken (vocabulary and screens, rules and controls, dashboards and reports customized to company needs, etc.).
• A package of preconfigured controls: usually based on good practice, for the company ERP.
• The ability to put in place controls on other applications, and between applications: over the medium-term.
• Analysis and decision support functionality: to highlight anomalies, simulate changes in permissions, conduct in-depth analyses, suggest remediation measures, etc.

Although the tools are generally not intrusive, in terms of their effect on applications, there’s still a need to automate the transfer of data, in a reliable way—from the ERP and other potential repositories. Involvement of the relevant IT teams will thus be needed too.

5. Getting things right for the long term

Projects of this type only make good sense if permission-related risks can be controlled effectively over the long-term. Doing so avoids the problem of risks that have been brought under control during the project appearing again—some time later.

To encourage long-term buy-in to the approach and tools put in place, it’s essential to invest in change management from the start—and throughout the project—by means of meetings and regular newsletters, training and coaching sessions, documentation and tutorials, etc. It’s best to use a diversity of channels and communication supports to reach the maximum number of people without giving the impression of over-marketing.

It’s also important to help those responsible for permission-related risks to apply new controls to their recurring activities. In fact, the frequencies of advanced controls, the objectives to be achieved, and the levels of risk that must not be exceeded, can be explicitly defined. These objectives must be realistic and progressive: “What’s needed is to envision a long road—but with short milestones.”

There must be an emphasis on community too: it’s important to encourage interactions between managers from different functions, which will enable them to share experiences and good practice. There may even be a value in introducing a degree of healthy competition between different business functions; perhaps even organizing some low-key challenges. However, you should ensure that the fact of making progress is valued more highly than achieving any specific numerical objective, because the various work areas will have to progress from very different starting points.

Finally, an “ongoing” mode needs to be implemented—to ensure that permission-related risks remain under control once the project is completed. This should include:

• Choosing a designated contact for the methodology and tools put in place;
• Upskilling the technical teams to ensure in-service support for tools, and that reports and controls can be developed when necessary;
• Documenting and capitalizing on the knowledge acquired during the project phase.

This must give consideration to developing a roadmap for other future activities that will address new processes, risks, applications, or populations.

Long-term control of the risks related to ERP permissions

In conclusion: it can be done!

As we’ve seen in the two articles on this topic, controlling the risks related to ERP permissions means pursuing a number of key workstreams—from putting in place the right tools, through holding workshops for the business functions, to training and change management.

But with a good methodology and committed participants from IT and the business functions on board, anything is possible! Tangible results can be achieved—and corporate momentum built—within a reasonable timeframe, to regain control of permissions across the IS. And, lastly, the key success factors presented here are broadly applicable to applications other than ERPs.

Cet article ERPs: How to control permission-related risks (PART 2) est apparu en premier sur RiskInsight.

And statutory auditors, internal controllers, and auditors, are only too well aware of this; they’ve been increasing pressure for several years now to bring these risks under control and ensure compliance with the relevant regulations.

ERP permission-related risks that need to be brought under control

What’s needed is to take a serious look at the topic of “permissions ” (which are also called rights, authorizations, roles, or access profiles). In fact, the permissions granted to users on a company’s ERP enable them to carry out a large part of their activities—legitimate or otherwise. By ensuring you provide only the right people with the right permissions at the right time, you can significantly reduce the risks mentioned above.

Over two articles, we present our vision for this area, and share proven good practices that can bring the risks associated with ERP permissions under control.

Companies show little rigor when it comes to ERP permissions

ERP ecosystems are complex, and companies typically spend a great deal of time and energy setting their ERPs up. Yet a minimalist approach is often taken to the “identity and access management” aspect of ERPs. Over time, this results in a deterioration in levels of control and security:

• Obsolete, generic, and shared accounts accumulate.
• The number of roles explodes.
• The principle of least privilege is not properly applied.
• Toxic combinations of rights (infractions of the segregation of duties principle) occur, etc.

All of these factors tend to increase the risks mentioned above.

Key Success Factors for an ERP permissions risk-remediation project

As a result, few companies can claim to have complete mastery of the identities and permissions aspects of their ERPs. To illustrate this, consider the indicative questions below to assess your understanding of the subject:

• How many accounts can’t actually be associated with a single individual (generic accounts, accounts not reconciled with an HR repository or Active Directory, etc.)?
• How many users can change the access rights of other users?
• How many users have profiles with high levels of privilege (such as “SAP_ALL” and “SAP_NEW” in SAP ECC)? Of these, how many are really legitimate?
• How many users can change the suppliers master data?
• On average, how many roles are assigned to users? Is it typically two or three roles per user, or do numbers of roles often reach double digits?
• How many IT roles are assigned to business-function users and vice versa?
• How many roles give more rights in reality than they should theoretically provide (roles that should be read-only but have write permissions too; roles whose applicability is broader than it should be; etc.)?

How can you address the issue?

Now that the problem has been defined, what can be done about it? It’s important not to feel overwhelmed or discouraged by the apparently huge task that the issue suggests! It is possible to improve the situation and bring risks related to ERP permissions under control. In addition to the obvious point of providing sufficient resources to do it, there are a number of key success factors that must be met; and these that are the subject matter of our two articles.

1. Steering things carefully

When embarking on such a project, you clearly can’t address everything straight away. It’s more a case of strategically targeting defined scopes which will yield significant results within a reasonable amount of time. For example, it might be a key application or a central ERP module, a process that’s been highlighted in a recent audit, or a series of risks already identified as critical in the corporate risk register. The analysis of real data extracted from ERP systems can be a great help in knowing what to prioritize, and in justifying the priorities chosen.

In terms of approach, there are three areas that the project must cover:

• The analysis and control of permission-related risks—the core work of such a project.
• Implementing a technical solution that supports the chosen methodology.
• Steering and change management—both essential for the success of such a project.

It’s important to pace the project by incorporating regular milestones for each of the three areas—and for each project phase:

• The preparation phase, which includes the detailed framing of the project, putting in place the tools, and completing the prerequisites.
• The deployment phase—known as Get-Clean—aims to control the current risks, by demonstrating the approach at pilot scale, rolling it out more widely, and adjusting the tools according to user feedback.

The ongoing operating mode—known as Stay-Clean—can take the project to the next stage, but the groundwork for it must be done during the initial phase, if the risks are to be controlled over the long term.

A model approach to an ERP permissions risk-remediation project

It’s imperative to closely monitor the actions taken by the various people and decision makers involved, and, more generally, to check that the commitments made at each step are being successfully achieved. These commitments can be represented by results that are both quantitative (a reduction of X% in the number of critical risks; no more than 5 risks per user, etc.) and qualitative (the development of processes or compensatory controls). There will also be a need to measure and demonstrate the value of these results to the project’s sponsors and representatives from the business functions.

2. Preparing the ground

Technical and business-function-related questions are closely linked in projects that address permissions, something especially true in the case of ERPs. As a result, you need to put in place the right sponsors from the start: from both the security and IT sides, and the business-function and Internal Control sides.

There may also be a need to involve numerous other players: access rights officers, security managers, representatives from the business functions, process managers, team managers, internal controllers, etc. Coordination is essential throughout the project, and future contributors, as well as those affected by the changes, need to be brought on board and engaged from the start—in terms of sharing the challenges, objectives, and approach. The approach must be framed positively: it must not be about stigmatizing states of affairs or behaviors, or comparing one part of the business with another; rather, it should be about moving the company and its employees forward in the management of risks.

The preparation phase first involves gathering the various inputs needed for the project, and especially those that will enable an initial analysis of the data: organizational information about users (department, function, etc.), permissions, access logs, control repositories, segregation of duties matrices, etc. For this last item, in particular, workshops are a must if the matrices are to be completed and “translated” into technical permissions that can become automated controls within a tool.

There is also a need to define the indicators, dashboards, and reports that will be used both during the project phase and also in the long term by those in charge of continuous monitoring.

Another important activity during this preparatory phase is to improve data quality. This prerequisite becomes all the more indispensable when a company’s maturity level, in identity and access management terms, is low. Improving quality isn’t just about user accounts though, it’s also—and especially—about the ERP authorization model. If the roles or access profiles themselves carry risks (in particular, in terms of the segregation of duties), this must be remedied before tackling the individual risks introduced by users.

Examples of prerequisites for an ERP permissions risk-remediation project

We’ve now discussed the first two key success factors in an ERP permissions risk-remediation project: close steering and preparing the ground. Three other key success factors will be discussed in a second article, to follow.

Cet article ERPs: how to control permission-related risks (Part 1) est apparu en premier sur RiskInsight.

Dans un précédent article, nous évoquions l’importance d’une bonne relation Métiers-DSI, sachant qu’un ensemble de leviers centrés autour de la valorisation du capital humain peuvent être actionnés.

Dans ce cadre, nous avons identifié sept rôles clés à installer ou à renforcer dans les organisations, tant côté Métier qu’au sein de la DSI. Ce sont la qualité et l’efficacité de leurs interactions directes au quotidien qui vont concrétiser et rendre visible l’apport de valeur de l’IT.

Deux rôles pour garantir l’apport de valeur IT

La performance opérationnelle et économique de la majorité des entreprises repose sur la bonne intégration des processus et de l’IT qui permet d’industrialiser les processus clés, tout en garantissant leur évolutivité. Dès l’émergence d’une demande métier associée à des objectifs de productivité interne et/ou un enjeu commercial, il faut évaluer quelle part de réponse peut être apportée soit par l’évolution des procédures métiers soit par l’IT. L’estimation globale des coûts et bénéfices va ensuite conduire à définir le périmètre exact d’évolution à faire porter par l’IT.

Des Business analysts pour améliorer la conception

Dans environ 2/3 des entreprises françaises, l’emploi d’« analyste métier » n’a pas été déployé suffisamment. Il est resté axé principalement sur les compétences de traduction des demandes métier en exigences, et sur celles de rédaction de spécifications fonctionnelles. Les processus métiers ne sont pris en compte que lors de la rédaction des supports de formation utilisateurs dans le cadre de la conduite du changement. Ce mode de fonctionnement montre ses limites. Aujourd’hui, le Business analyst doit être en capacité d’identifier, de clarifier, d’analyser et de documenter les besoins de l’entreprise et la valeur associée. Il travaille à traduire les besoins de l’entreprise en objectifs fonctionnels et techniques, en garantissant la valeur générée. Il participe ainsi à la recherche de solutions innovantes, tant IT que processus, afin de répondre aux besoins Métiers identifiés. Il est donc « en charge de l’efficience des organisations et de l’amélioration des processus, des services et des produits, depuis l’analyse initiale des besoins jusqu’à la conduite du changement ».

Dans cette recherche de solutions maximisant la valeur générée pour l’entreprise, les Business analysts travaillent étroitement avec les concepteurs IT et les métiers. Ces deux rôles (Business analyst et concepteur) sont même amenés à fusionner dans le cas d’équipes agiles ou de progiciels.

Des Business process owners pour garantir la performance des processus

Dans le dialogue avec les Métiers, les Business analysts doivent s’appuyer sur les Business Process Owners (BPO). Ces BPO Métiers ont la responsabilité de la performance d’un processus d’entreprise (mesurée par des KPI). Ils ont le niveau de responsabilité et les compétences pour décider et faire mettre en œuvre les changements nécessaires. Afin d’améliorer la performance opérationnelle, le BPO pourra par exemple proposer de spécialiser une équipe sur une activité, ou bien a contrario de centraliser un ensemble d’activités sur un groupe de collaborateurs. De son côté, le Business analyst missionné sur une demande métier sollicitera le BPO pour définir les changements envisageables sur les processus impactés dont ce dernier a la charge. Cette responsabilité de BPO n’est pas à date toujours clairement identifiée dans les entreprises, notamment en raison de la responsabilité transverse qu’elle implique dans le pilotage de processus impactant plusieurs directions. Dans le cas où les BPO n’existent pas, les Business analysts auront un rôle accru. C’est sur eux que reposera la constitution d’une vision transverse des besoins et des processus impactés. Ils devront être force de proposition sur le bon équilibre d’évolution en termes de processus et d’IT.

Deux rôles pour intégrer la voix des utilisateurs dans la chaîne de valeur IT

La multiplicité des offres et l’interpénétration des canaux de la relation client se traduisent par une complexité accrue des postes de travail utilisateurs, non seulement en front-office mais également en back-office.

Leur environnement évolue régulièrement suite à des demandes qui s’enchaînent et s’entrecroisent, venant des directions commerciales, marketing, juridiques, financières… Inévitablement, il devient de plus en plus difficile de garantir une ergonomie des positions de travail permettant une exécution performante des différentes procédures et activités qui sont mises en œuvre au sein de chaque équipe opérationnelle. Cet aspect global est imparfaitement pris en compte dans l’expression des demandes métiers, souvent axées sur des évolutions d’offres et de services. Cela peut parfois aller jusqu’à la dégradation de la performance de certaines équipes et même du climat social, souvent perceptible par les clients finaux. Pour y répondre, les équipes IT doivent intégrer la voix des utilisateurs dans la chaîne de valeur IT afin d’améliorer la qualité de service rendue et la piloter efficacement dans le cadre du partenariat business-IT.

L’objectif est d’aller au-delà de la vision technique du poste de travail et de renforcer la légitimité de la DSI dans la connaissance de la perception terrain des outils mis à disposition dans l’entreprise. Pour cela, il leur faut développer la mesure de la satisfaction utilisateur et les dispositifs qui vont permettre d’identifier et de mettre en œuvre les actions d’amélioration nécessaires.

Des Key users pour incarner la « voix des utilisateurs »

L’identification de Key users côté Métier, au sein des unités opérationnelles de l’entreprise (plateau de vente, agence bancaire…), est primordiale, car ce sont les utilisateurs eux-mêmes qui sont les mieux placés pour identifier ce qui peut leur apporter plus d’efficacité dans leur travail au quotidien. Le Key user, c’est la combinaison entre la vision terrain maîtrisant très bien le métier et la capacité à prendre du recul pour identifier les trucs et astuces qui font gagner du temps. Le rôle du Key user permet de détecter des « signaux faibles », ou « irritants » qui pénalisent la satisfaction utilisateur (trop de copier / coller entre écrans, mise à jour d’une donnée trop tardive pour mener à bien une procédure…). Il est donc impliqué dans des boucles d’amélioration qualité qui vont au-delà d’une sollicitation ponctuelle dans le cadre de recette et d’UAT (User Acceptance Test).

Des Representant users pour porter les attentes des utilisateurs

Le Key user dispose toutefois d’une voix trop faible au sein des équipes IT. Il est donc nécessaire que la DSI lui associe un Representant user, côté équipes IT, qui va qualifier et relayer intelligemment les demandes des utilisateurs en s’assurant qu’elles sont traitées au bon niveau.

Jouant le rôle de Business analyst sur un périmètre « Environnement/position de travail », le Representant user qualifie, centralise, priorise les demandes des utilisateurs et mobilise les bons interlocuteurs afin de les insérer dans les projets/évolutions en cours. Il représente les utilisateurs en phase d’étude et s’assure de la cohérence et de la qualité des formations utilisateurs dans une vision d’ensemble des projets en cours. Il propose les objectifs chiffrés d’amélioration de la satisfaction utilisateurs pertinents sur son périmètre. Sa nomination doit être basée sur les compétences de leadership, d’intermédiation et de communication.

Trois rôles pour garder le cap de l’alignement du SI avec l’entreprise

Les rôles évoqués précédemment ont leur propre valeur. Pour en tirer pleinement parti, il est essentiel de les coordonner à différents niveaux.

Des Client managers pour renforcer la proximité avec les Métiers

Le Client manager incarne personnellement la proximité avec un ou plusieurs métiers clairement identifiés. Il est responsable de la qualité de l’animation de la relation Métiers – DSI et organise les comités opérationnels de suivi de cette relation, tant sur le suivi des investissements que sur la qualité du service rendu. Il est présent au Codir Métier. Il est le point d’entrée de toute nouvelle demande et est fortement impliqué dans le pilotage du portefeuille projet et la construction des schémas directeurs sur son périmètre.

Bien plus qu’un responsable de compte, il représente au sein de la DSI le(s) Métier(s) dont il est l’interlocuteur privilégié et s’assure de l’appropriation de leurs enjeux au sein des équipes IT, grâce à sa double compétence Métier-IT. Il est garant de la cohérence des solutions mises en place pour un Métier donné. Il est force de proposition et facilitateur en cas d’arbitrage à faire valider par le Métier, notamment pour expliquer les coûts de run impliqués par le projet. Il apporte sa vision globale des enjeux métiers aux Business analysts et aux Representant users afin de rendre leurs propositions plus pertinentes. Il s’appuie sur le(s) Service(s) Delivery Manager(s) qui pilotent opérationnellement la qualité des services récurrents et avec qui il définit les orientations à suivre en termes d’amélioration continue (évolution des engagements, plan d’action qualité sur un périmètre applicatif…). Le Client manager occupe généralement un poste de manager des équipes SI pour un domaine métier donné.

Un Chef de projet solutions pour s’engager d’une seule voix auprès des Métiers

Dans la plupart des organisations, la responsabilité d’un projet est portée par trois chefs de projet, l’un métier, le deuxième MOA et le troisième SI / MOE.

Pour autant, l’une des principales difficultés rencontrées actuellement dans le delivery des projets est la dilution des responsabilités entre les différents acteurs mobilisés dans un projet et la déresponsabilisation du ou des chefs de projet nommés côté MOA et MOE. Il est essentiel de redonner du poids à la gestion de projet en nommant un unique Chef de projet solutions, portant la responsabilité MOA et MOE en regard des Métiers et intervenant dès les phases d’étude. Il doit disposer de l’ensemble des moyens (économiques, opérationnels) pour s’engager. Il challenge les besoins et la valeur de la solution identifiée, il dispose d’un pouvoir décisionnel sur les moyens nécessaires pour délivrer la solution et est l’interlocuteur clé pour les Métiers sur le projet qu’il pilote.

Le Chef de projet est aujourd’hui un acteur incontournable dans la relation Métiers-DSI. Il porte la responsabilité de délivrer la solution, alignée avec les demandes relayées par le(s) Business analyst(s) et le(s) Representant users et avec les enjeux métiers relayés par le Client manager. Il est garant du respect des engagements réciproques Métiers et IT dans le cadre du projet et s’assure de la bonne intégration de la solution dans le SI existant et à venir (performance fonctionnelle et technique et optimisation des coûts en build et en run).

Il doit être choisi en fonction de l’enjeu, de la complexité du projet et du niveau d’impact sur le SI. Par exemple, dans le cas d’un projet dont le facteur clé de succès est essentiellement l’évolution des procédures opérationnelles métier, un acteur MOA ou venant du métier pourra être nommé Chef de projet, renforcé éventuellement avec un profil type PMO.

L’Architecte d’entreprise pour garantir l’alignement stratégique et la cohérence du SI

Il faut de plus assurer la cohérence globale des initiatives lancées par chaque Métier d’un point de vue entreprise (stratégie générale et orientations SI) grâce à un rôle clé : l’Architecte d’entreprise. Il intervient en tant que référent de l’architecture IT de l’entreprise et est garant de la cohérence globale de l’évolution du SI avec la stratégie et les processus d’entreprise. Il définit la stratégie d’évolution du SI et avalise les évolutions dans un souci d’alignement. Il est l’animateur de la communauté d’architectes qu’ils soient fonctionnels ou techniques. Il exerce son devoir de conseil en identifiant les solutions transverses pertinentes. Enfin, il est un conseiller avisé des Business analysts et des Chefs de projet solutions et les aide à optimiser leurs investissements dans le respect des orientations stratégiques.

In fine, c’est en renforçant l’ensemble de ces « nouveaux » rôles dans l’entreprise que se tissera pas à pas une relation Métiers/DSI de confiance durable à même de servir toujours mieux la stratégie globale de l’entreprise.

Cet article De nouveaux rôles pour transformer la relation Métiers – DSI est apparu en premier sur RiskInsight.

Guy Bellot : Au cours des dernières années, dans une volonté d’industrialisation et de réduction des coûts, nos structures ont évolué vers des « centres de services » ayant recours à de l’externalisation. Les actions de massification ont mécaniquement entraîné une concentration de l’activité sur quelques grands fournisseurs qui représentent aujourd’hui une part significative de la dépense IT.
Au vu de l’importance de ces fournisseurs dans nos activités IT, il est devenu essentiel de pouvoir à la fois :

• Accroître notre écoute respective, augmenter la visibilité donnée sur les attentes du business et aider à anticiper les variations de charge ;
• Objectiver la qualité de service fournie, par une mesure régulière et partagée d’indicateurs, en intégrant la vision d’un service « de bout en bout » délivrés aux utilisateurs finaux ;
• Garantir indépendance et souplesse pour Carrefour en favorisant la comparaison avec le marché tout en challengeant réversibilité et flexibilité des modèles déployés.

En étroite collaboration avec la Direction des Achats IT, le VMO doit animer et renforcer la relation de Carrefour avec ses fournisseurs stratégiques (au nombre de 6).

Quels en sont les premiers résultats ?

GB : Initié au cours du deuxième semestre 2012, le VMO a tout d’abord conduit une phase pilote qui nous a permis d’étoffer notre connaissance de nos fournisseurs et de tester la mise en oeuvre d’indicateurs suivant le principe des Balanced Score Card (BSC).
À ce jour, 3 outils correspondant à 3 niveaux d’information distincts sont utilisés ou en cours de déploiement :

• l’enquête de satisfaction semestrielle, qui nous permet de capter la perception des équipes IT quant à nos fournisseurs ;
• la BSC, qui complète la perception d’indicateurs de mesures sur les aspects performance financière, satisfaction client, performance des processus, ainsi qu’innovation et amélioration continue ;
• et enfin le dossier de suivi fournisseur qui enrichit les informations précédentes par d’un côté les informations externes (analyses financières, informations de tendances communiquées par les cabinets, retours d’autres grands groupes) et de l’autre les informations communiquées par le fournisseur (sa perception de son positionnement, de ses forces et ses faiblesses, ses retours sur l’enquête de satisfaction et les plans d’actions qu’il propose de mettre en oeuvre).

Ces dossiers sont construits et partagés avec les fournisseurs et avec les directeurs IT des entités et pays Carrefour. Ils permettent d’initier puis de suivre des plans d’actions, induisant ainsi une dynamique plus forte dans la relation.

Quels enseignements, quelles recommandations pour d’autres DSI ?

GB : L’animation du VMO demande un changement d’état d’esprit dans la relation. Il faut privilégier la transparence, la recherche de synergies, la collaboration avec nos partenaires et entre les partenaires. En même temps, il faut rester vigilant aux attitudes opportunistes, aux visions trop court terme, et aux situations de concurrence entre ces partenaires. Les modèles de sourcing doivent permettre de maintenir l’équilibre (dual sourcing). Il faut aussi adresser les bons niveaux hiérarchiques pour partager l’ambition et leur permettre de s’inscrire dans une démarche qui va demander du temps et de la maturité. Une phase pilote avec peu de fournisseurs (2 ou 3) sur un périmètre restreint permet assez vite d’identifier les limites et de régler les ambitions réciproques, pour ainsi sortir du diktat du « Quarter ».

Cet article 3 questions à Guy BELLOT (Carrefour) est apparu en premier sur RiskInsight.