MGLIIC 2024 Lectures Summary PDF

Document Details

ImprovingSchorl8722

Uploaded by ImprovingSchorl8722

Otto-von-Guericke-Universität Magdeburg

2024

Karl-Albert Bebber

Tags

IT systems process modeling business processes management

Summary

This document is a summary of lectures on the management of global large IT systems in international companies.

Full Transcript

Management of Global Large IT-Systems in international Companies (MGLIIC) Lecture – Summer Semester 2024 Otto-von-Guericke-Universität Magdeburg Selected Topics / Lectures Summary Karl-Albert Bebber 2024-06-15 Part 1: Process Modeling Business Processes and Process Modeling...

Management of Global Large IT-Systems in international Companies (MGLIIC) Lecture – Summer Semester 2024 Otto-von-Guericke-Universität Magdeburg Selected Topics / Lectures Summary Karl-Albert Bebber 2024-06-15 Part 1: Process Modeling Business Processes and Process Modeling Closed Action Workflow Process ReDesign and Improvements Process and IT System Landscapes page 2 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process Documentation Definitions A business process or business method is a cluster of related, structured activities or tasks that produce a specific service or product for a particular customer or user. It often can be described and visualized by a flowchart as a sequence of activities with interlaced decision points or by a Process Matrix as a sequence of activities with relevance rules based on the data in the process. page 3 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process Documentation BPMN = Business Process Modeling and Notation Ref: BPM Offensive Berlin 2011 page 4 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process Documentation Role of IT in Process Flows 1. IT Systems and Transaction are working in dialogue with a human role or they are handling one or more activities independantly 2. IT System is often a landscape of different IT-Systems, mostly communicating among each other. Therefore In a Process Flow the different IT Systems can be integrated as separate swim Lanes. You can also differentiate one IT System in different roles/swim lanes – but be careful - … page 5 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Closed Action Workflow For any cooperation and collaboration between two partners/roles/departments/ … a closed “Action Workflow” is helpful / is needed: 1. Partner 1 hands over task / request / order … to Partner 2 2. Partner 2 understands / agrees / accepted … 3. Partner 2 fulfills / produces … and delivers … to Partner 1 4. Partner 1 accepts and takes over page 6 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Closed Action Workflow 1 customer 2 supplier Requests a service agrees to do it (Inquiry phase) (Commitment Phase) Would you Yes, I will! please...? Great, thank you! Done! 4 customer 3 supplier accepts the result and does the work and Declares satisfaction signals completion (Evaluation Phase) (Fulfillment Phase) page 7 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process ReDesign / Improvement Starting Point For every IT Project there is a business need: Mostly Process Improvements or Process ReDesign are required to reach cost savings higher quality legal requirements new business … In most cases there are no or no sufficient or no consistent documentations of Processes Supporting IT-Systems Maintaining Procedures … etc. page 8 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process ReDesign / Improvement AS IS Analysis: weaknesses Process and Data Modeling is one of the most important steps to reach an overview about AS-IS but also to find out: What are historical activities no longer needed (events and results have no connection)? Which activities are redundant, which - may be - are even conflicting (infinite loops, …)? Which roles do exist (Swim lanes) and are the role definitions correct and according to Organizational Design? Which processes are highly complex and could be simplified (e. g. too many swim lanes, to many forks and lanes crossings, …)? Overload or underload of capacities? page 9 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process ReDesign / Improvement TO BE Design: Harmonizing + Standardizing Therefore it‘s simple to understand: Harmonizing and Standardizing is a question of survival! … not only for surviving but also … for creating comparability for generating synergies and saving costs for implementing group strategies for being independent of locations, regions, countries, … for simplifying Mergers and Acquisition (M&A) activities … page 10 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process ReDesign / Improvement TO BE Design: Harmonizing + Standardizing On the other hand: Opportunity to make clear whether there are really reasons to allow and design exceptions …. based on Legal requirements Business needs Location dependencies Work council agreements … page 11 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process and IT landscape Mandatory Settings Given a distributed architecture of different functional and technical IT systems Defining mandatory settings – on general level – on functional level – without any conflicts or minimal conflicts among each other Defining a leading system for every cluster of mandatory settings (i. e. on the business side: a responsible business unit) Defining and implementing synchronization procedures between the systems Defining and implementing synchronization controls for the whole landscape How to handle conflicts? (decision board) How to maintain Mandatory Settings? page 12 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Process and IT landscape Mandatory Settings - examples Master Data...... Posting periods Ranges of data values Roles and Access Rights Authorization Management Rules Posting rules Tax calculation rules Valuation rules for goods Documentation policies Archiving policies Exchange Rates Rules (which rate is taken in which case …)... page 13 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Part 5: Quality and Risk Management Quality Management Risk Management Testing Lessons Learnt page 14 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Quality Management Definitions Quality Management is the management of the processes which are determining quality policies, objectives, and responsibilities for all involved people and units in order that a project will satisfy the goals and needs for which it is started. It should be supported by efficient rules and proactivly accompanied and monitored by accepted and highly motivated people. Quality Management is therefore a core part and task of Project Management. page 15 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Quality Management Content and Tasks Managing the Triangle Quality Costs Time by Rules for Documentation Management of change requests/changes within the Project Management of support processes during the Run Management of Risks within the Project and during Run Measures for Quality and Quality Controls Integration of external and internal Audits page 16 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Quality Management External vs. internal view Quality Management has to fulfill Project external requirements and expectations Project internal needs and expectations Quality Management Tools and Methodologies are perfectly made for covering the external view on the project and on projects qualilty. There is often a lack of acceptance and understanding in the internal project team: too much overhead additional work conflicts of time formalism vs. content of workpackages parallel activity producing redundancies … page 17 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Risk Management Definitions Risk is a future event, which can be occur with a certain likelihood and which can influence previously defined objectives in a negative way. Risk Management is a supporting instrument, which allows all involved parties to identify, evaluate and manage the risks. Identifying Evaluating Managing Monitoring Risks Risks Risks Risks page 18 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Risk Management Risk Assessment Evaluation scheme for qualitative risk evaluation ▪ Implementation and Management of projects is unavoidably linked to risks. 3 4 5 high ▪ To steer and to manage these risks is the occurrence probability main content and the main task and challenge of Risk Management as part of the Quality/Project Management. medium ▪ The list of risks contains all impact aspects 2 3 4 and all general conditions lined and joined with the risk (concerning time, costs, quality). ▪ All identified risk will be categorized depending on probality and impact to the 1 2 3 low project in five risk classes. Depending on this classification the measures and the handling should be designed and planned. low medium high Impact for the project (milestones, costs, quality) page 19 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Risk Management What is to do? Risk Management Lifecycle 1. Identifying Risks 2. Evaluation of risks - if a risk would occur - in terms of quality, costs and time 3. Estimation of probability 4. Defining qualified Measures for Minimizing Risks 5. Preparing and implementing Measures 6. Defining adequate and validated fallback scenarios 7. Preparing and integrating fallback scenarios 8. Ongoing Monitoring / establishing of escalation mechanism page 20 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Testing Positioning within a project Enough time for testing If possible: separate test environment Developers testing and Unit testing Integration Tests and End-to-End Testing Simple but efficient test documentation (test cases and results) Test cases should be generated during Process Design (time with highest awareness for critical steps and parts of the processes) Test cases should be reproducible Test cases should be repeatable Test cases should be reusable for every test requirement also after GoLive page 21 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Testing Some important Test Procedures 1/2 Unit Test Test of a module or part of a module containing one main functionality (or only a few functionalities) e. g. PRINT Module or Result of a mathematical calculation (mostly performed by the developer/programmer himself) Integration Test Test of a whole process or subprocess e. g. test of a posting process for accounting or test of a hiring process for an employee (mostly performed by the business within a User Acceptance Test(UAT)) User Acceptance Test (UAT) Test of the business (=user) in order to have a base for approving the new application/system page 22 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Testing Some important Test Procedures 2/2 Regression Test Having changed only a part or some parts of an application then the changed parts will be tested by Unit Tests and/or Integration Tests; Regression testing does confirm that the non changed parts of the application are still running as before Stress and Performance Test Performance Test are testing the performance of an application i. e. whether the application does fulfill the functionalities in the required time schedule Stress Test are test under extreme conditions i. e. e. g. with many parallel users (significantly more than normally) or using all functionalities synchronously page 23 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Lessons Learnt Session How to handle and to manage …? Continuous Improvement Process also for Implementation Projects and Running Systems therefore during and at the end of the project collect and generalize lessons learnt Enabled by one central role Describing an example (to understand) and making a generalization Not only things and experiences gone wrong but also successes and positive achievements for implementing already measures in the running project For the next or following project(s) At the end of every project: Make a Lessons Learnt Session page 24 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Part 4: Agility Sequential IT Project Management / Basic Definitions Agile Project Management Methodes Agility + Disruption vs. Waterfall + Continuity Miscellaneous page 25 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agenda Sequential IT Project Management / Basic Definitions Agile Project Management Methodes Agility + Disruption vs. Waterfall + Continuity Miscellaneous page 26 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agile Project Management Methodes Source: https://www.linkedin.com/pulse/what-agile-scrum-oscar-rugama page 27 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agile Project Management Methodes Feb 2001 Source: http://agilemanifesto.org/ page 28 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agile Principles Principles behind the Agile Manifesto We follow these 12 principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. page 29 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agile Principles Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. page 30 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agile Principles Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. page 31 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agile Project Management Project objectives are made clear by the customer while the final deliverable can change. The project team works in iterative cycles, always evaluating results at the end. Depending on the results of these evaluations, the final deliverable may be modified in order to better answer the customer’s needs. Continuous collaboration is key, both within the project team members and with project stakeholders. Source: https://www.wrike.com/project-management-guide/methodologies/ page 32 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Scrum What is Scrum? Scrum helps people and teams deliver value incrementally in a collaborative manner. If you are just getting started, think of it as a way to get work done as a team in small pieces at a time, with experimentation and feedback loops along the way. from the page: https://www.scrum.org/ page 33 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum https://www.agile42.com page 34 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum Which roles do we have in scrum? In the scrum team there are 3 main roles: Product Owner, Developer and Scrum Master. The Product Owner is the contact to the stakeholders and she/he collects in the Product Backlog all requirements from: https://www.mitsm.de/ The developers are realizing the requirements. The Scrum Master is the coach and supports the team of developers. page 35 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum How the scrum method does work? A subset of the defined product requirements in the product backlog is realized in a fixed time period, a so-called sprint. For this purpose, a sprint backlog is created at the beginning of such a sprint, in the sprint planning. The requirements are then implemented by the developers during the sprint. There is a Daily Scrum on each working day of the Sprint. This is a short appointment in which the current state of development is synchronized. from: https://www.mitsm.de/ The result of the sprint is a product increment, so to speak a new product version, which is presented to the stakeholders at the end of the sprint - in the so-called Sprint Review. Feedback is constantly obtained during the development process. A sprint retrospective follows, in which the Scrum Team reflects on the last sprint. This improves processes and increases efficiency. The cycle then begins again: a new sprint backlog is created based on the product backlog. page 36 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum - Roles What is a scrum master? Scrum masters are the facilitators of scrum, the lightweight agile framework with a focus on time-boxed iterations called sprints. As facilitators, scrum masters act as coaches to the rest of the team. “Servant leaders” as the Scrum Guide puts it. Good scrum masters are committed to the scrum foundation and values, but remain flexible and open to opportunities for the from: https://www.atlassian.com/ team to improve their workflow. page 37 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum - Roles What’s a developer? The development team includes the people that do the work. At first glance, you may think the “development team” means engineers. But that’s not always the case. According to the Scrum Guide, the development team can be comprised of all kinds of people including designers, writers, programmers, etc. You can think of it in the same way as when you have a house project and you hire a developer. They develop the project and do the work. Yes, this from: https://www.atlassian.com/ might mean they lay bricks, do plumbing, even dig holes, but the person is known as a developer. So, that means the ‘developer’ role in scrum means a team member who has the right skills, as part of the team to do the work. page 38 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum - Roles What is a product owner Scrum product owners understand the customer and business requirements, then create and manage the product backlog based on those requirements. Since agile teams are, by design, flexible and responsive, it is the responsibility of the product owner to ensure that they are delivering the most value. The business is represented by the product owner who tells the development what is important to deliver. Trust between these two roles from: https://www.atlassian.com/ is crucial. The product owner should not only understand the customer but also have a vision for the value the scrum team is delivering to the customer. The product owner also balances the needs of other stakeholders in the organization. page 39 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum What is a product backlog? A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product from: https://www.atlassian.com/ owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum). page 40 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum What are sprints? A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches. from: https://www.atlassian.com/ "Sprints make projects more manageable, allow teams to ship high-quality work faster and more frequently, and gives them more flexibility to adapt to change." page 41 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Scrum What the daily stand-up (daily scrum)? a stand-up is a daily meeting that involves the core team: product owners, developers, and the scrum master. This meeting’s flavor is unique to each team, but there should be answered this three simple questions to generate structure: – What did I work on yesterday? – What am I working on today? from: https://www.atlassian.com/ – What issues are blocking me? These questions highlight progress and help flag team blockers. Also, it strengthens the team when everyone shares the progress they’re contributing to the team. The daily reinforcement of sharing individual successes and plans keeps everyone excited about the team’s overall contribution to the organization.. page 42 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Part 5: Agility Agenda Sequential IT Project Management / Basic Definitions Agile Project Management Methodes Agility + Disruption vs. Waterfall + Continuity Miscellaneous page 43 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agility + Disruption vs. Waterfall + Continuity Often there are these different approaches not only when managing projects (IT or Business) but also when doing product development innovating or redesigning business processes leading and developing teams and employees reorganizing groups, legal entities, departments doing … In the following some examples … page 44 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agility + Disruption vs. Waterfall + Continuity In this week EuGH (European Court of Justice) decided: that in all companies in Europe the working time has to be always documented This did and does raise the question and discussion Flexible working time and working schedules enabling doing tasks when needed and being self responsible for what you do in which timeframe vs. Having clear rules for management of working time caring for employees in order not to risk health and privacy making a clear separation between private time and working time page 45 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agility + Disruption vs. Waterfall + Continuity Leading people and organization Building networks and enabling experience exchange enabling doing tasks when needed and being self responsible for what you do in which timeframe vs. Strong „Leadership“ and giving obligating orientation allowing no freedom for own decisions and risks being as boss at every time „auditable“ and knowing what‘s going on in my unit page 46 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Agenda Sequential IT Project Management / Basic Definitions Agile Project Management Methodes Agility + Disruption vs. Waterfall + Continuity Miscellaneous page 47 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Miscellaneous Programm Management is the Management of different projects running under one umbrella – caused or triggered by the same business need (e. g. by a merger or a carvout) Project Portfolio Management does manage the whole project portfolio of an organization; esp. in IT departments there are always many parallel projects which have to be managed e. g. by similar methods and are requiring same capacities. Multi Project Management is needed when several project are running in overlapping time frames but being mostly independent. page 48 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Part 2: Identity and Access Management Objective: what are the current challenges, how IAM can help and which Lessons Learnt are already made. Current challenges for everybody and for Global Companies Identity Management as solution idea Basic Definitions Important functionalities Benefits & Overview Solution Market Critical Success Factors & Future Challenges page 49 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Current Challenges – on company / group level p1/2 1. There are many different devices, applications and enablers to be used within a company – to be used by one employee 2. Most of the different applications have their own (different!) philosophy concerning Accounts, Passwords, Access Rights, Access Policies,... Etc. 3. Access Management for these applications is historically driven 4. When changing your position you need other applications – the access to not longer needed ones are often not eliminated 5. When joining the company you need a basic set of accesses to applications and devices – when leaving the company every access has to be elimated. 6. So called „Machine Users“ have to be managed. page 50 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Current Challenges – on company / group level p2/2 7. In many companies: nobody is able to answer the question „which employee has which access to which application?“ 8. Are „Segregation of Duties“ (SoD) and „Four Eyes Principle“ assured? 9. Do exist so called „orphan accounts“ – accounts which are not assigned to an existing user. 10. Password Reset Management – well assured and documented? 11. Clear and common used procedures for providing access rights? 12. How to handle „Rejoining the company“... e. g. as an external consultant? page 51 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary A general solution is needed: Identity Management p1/3 Definition based on Wikipedia: Identity and Access management (IAM) is the security and business discipline that "enables the right individuals to access the right resources at the right times and for the right reasons." page 52 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary A general solution is needed: Identity Management p2/3 It addresses the need to ensure appropriate access to resources across increasingly heterogeneous technology environments and to meet increasingly rigorous compliance requirements. The terms “Identity Management" (IDM) and “Identity and Access Management“ (IAM) are used interchangeably in the area of Identity Access management …. page 53 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary A general solution is needed: Identity Management p3/3 Identity Management Systems, Products, Applications and Platforms manage identifying and ancillary data about entities that include individuals, computer-related hardware and applications. based on https://en.wikipedia.org/wiki/Identity_management page 54 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p1/7 Within a given Corporate Identity Management Framework (e. g. of a global group like Volkswagen or Amazon or...) an Identity is the central entity which can be a Person, a piece of Software or a piece of Hardware and which is described by attributes like first name, last name, birth day,... to make the identity unique. page 55 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p2/7 Within a given Corporate Identity Management Framework (e. g. of a global group like Volkswagen or Amazon or...) Concerning used Applications an Identity can have one (or maybe more) Account/s for a specific Application (e.g. User-ID for a SAP Application, E-Mail-Adress for a Mail-System,...etc.). This Account identifies the Identity within the Application. An Account is belonging uniquely to an Identity. page 56 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p3/7 Within a given Corporate Identity Management Framework (e. g. of a global group like Volkswagen or Amazon or...) Within an Application one or more Roles can be assigned to an Account. Roles are Bundles of Access Rights (e. g. Administrator Role, Role of only viewing or changing or deleting or creating data... etc.) page 57 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p4/7 IAM-Level Application Level Identity 1:n Account Account described by n:m Attribute 1 Attribute 2 Role 01 Attribute... Role 02 Role... page 58 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p5/7 IAM-Level Application Level Identity 1:n Account Account Authentication: described by n:m For showing and confirming that a logging in „Identity“Attribute is really1 the Identity belonging to an „Account“ Attribute 2 an Authentication Procedure Role is needed; 01 Attribute... based on so called Authentication Criteria as Role 02 Passwords, PIN‘s or by biometric information or Role...... (i. e. criteria only known or owned by the „Identity“). page 59 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p6/7 IAM-Level Application Level Identity 1:n Account Authorization: For assigning the needed access Account rights to an „Account“ described byan n:m Authorization Procedure is Attribute 1 needed; these access rights are Attribute 2 Role 01 based on theAttribute „Roles“... assigned to Role 02 the „Account“. Role... page 60 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Basic Definitions and Data Model p7/7 IAM-Level Application Level Identity 1:n Account Account Single Sign Ondescribed (SSO): by n:m If within a Process / System Landscape only Attribute 1 Procedure is needed (by one Authentication Attribute 2 Identity...only for the IdentityRole 01 verifying the Attribute Management System) this user friendly Role 02 functionality is called: Role... „Single Sign On“ (SSO). page 61 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Two-Factor Authentication (2FA) p1/3 IAM-Level Application Level Methods/Procedure Identity 1:n of Authentication: Account Authentication is becoming more and more a very important topic (Security!) Account I. e. theredescribed are needs by for making the autentification n:m procedure more and more secure Problem: If someone Attribute 1 else gets the knowledge about your PIN, passwordAttribute … etc.2 Role 01 One ideaAttribute... for solving: Two-Factor Authentication Role 02 (2FA) Role... page 62 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Two-Factor Authentication (2FA) p2/3 IAM-Level Application Level Two-factor (two-step) Authentication (2FA): Adding a second layer Identity 1:n in the Authentication Account procedure There are 3 types of authentication steps: Something you know – e. g. a password, a PIN, zip code or an answer to a question … Account Something you have: described by a phone, a credit card, a token, … n:m Something you are: a biometric e. g. a fingerprint, retina, face or voice, … … andAttribute 2FA combines 1 two of this steps: e. g.Attribute after having 2 entered your password you get a text („2FA code“) via Role 01 SMS Attribute which you...have to enter within a limited space of time Important: the 2FA-code is used only one timeRole 02 Role... Source: Two-Factor authentication: how and why to use it https://www.cnet.com/how-to/how-and-why-to-use-two-factor-authentication/ page 63 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Two-Factor Authentication (2FA) p1/3 IAM-Level Application Level Examples of 2FA‘s: Identity Entering Account +1:n Password -> getting Accountan SMS with a 2FA-code on your smartphone -> entering this 2FA-code Open your smartphone with a fingerprint -> entering a password before using the smartphone Account … described by n:m Increasing level of security by Multi-Factor Authentication by combining Attribute 1more different authentification steps Keep inAttribute mind: 2 Role 01 Attribute It‘s always... of consideration: a matter Role 02 needed security level vs. effort and acceptance Role... page 64 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary How an IAM does work? p2/2 Application... System HR The IAM is feededby the relevant Changes managed in the HR System Administration of Roles and Accounts and Relations between IAM Accounts and Roles Application 04 (Access Rights) are managed within IAM Application 01 And all relevant information is distributed via „Connectors“ to the impacted / involved Applications Application 02 Application 03 page 65 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 01 Administration and Provisioning Administration and Maintaining of all relevant Data Provisioning is an important Identity Management procedure; it defines the different ways of managing an individual’s identity, authentication and authorization rights. Provisioning is the – creation, management and maintenance – of an end-user’s objects and attributes – in relation to accessing resources – available in one or more systems. page 66 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 02 Connectors (Interface) For getting the Identity Life Cycle Event Information a connector for the HR Systems are needed For distributing the changes of Identities and Account and Roles connectors to all connected Applications (Provisioning) These Connectors should be standard – i. e. using standard Software Components you can implement these Connectors out of the box Most connectors should be bidirectional – to ensure synchronization page 67 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 03 Reporting The Knowledge about which which individuals have access to which resources at which times and for which reasons should be available by standard reporting functionalities – maybe by an open interface to an Standard Data Warehouse Solution. page 68 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 04... Reporting additional important reports: Performance and capacity utilisation Unusual access attempts of the IAM itself Quality Reports e.g. – Synchronization Quality within the whole System Landscape – Regular As-IS Reports of Accesses in order to recertificate – Orphan Accounts –... page 69 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 05 Security The IAM System is the central pool for Access Rights and their administration - therefore the IAM Data Base and the IAM Application has to fulfill highest level of Security. Everybody is trusting in IAM vs. IAM the most vulnerable System. Security has to be secured by – Continuous Monitoring and Reporting – A very limited Number of IAM-Administrators – A very secure Authentification Procedure for IAM itself – Data and Interface Encryption Rules... page 70 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 06 Governance There are existing many Rules and Policies and Processes – for creating and building Accounts – for creating and changing Passwords – for defining Security Level and – the Access Management Process. IAM offers the Opportunity of Harmonizing and Making transparent these Rules and Policies. An IAM System should have the Function of implementing the harmonized Rules and Policies Data Ownership of all IAM Master Data page 71 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 07 Approval and Requests supported by Workflows For handling the needed request and approval steps a flexible workflow engine is needed. Workflow customizing should be feasable based on the IAM internal entities and their attributes. Workflows should be integrated in the normal communication flow of the company (e. g. by the used standard E-Mail-System). Workflows should have transparent fallback rules when being stopped for a longer time interval... page 72 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 08 Data Model based on time intervals For Administration and Monitoring and Reporting you need to handle multiple time intervals within IAM (e. g. Starting and Provisioning of an employee must be prepared already during hiring – that means: data and attributes have to be mainained in the IAM already for the future - before being valid). That means: Parallel Maintaining and Storing of Data for different time intervals must be possible. So it is also possible to rebuild Access Scenarios for already past periodes (s. Reporting and Auditing). page 73 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 09 User Friendliness and Self Services Many transactions within a IAM are made by Non-Experts e.g. – Password Reset Request – Approval of an Access by a Manager – Recertification Approvals by a Manager –... These transactions must be offered within the Group- Intranet in a very simple and user friendly way otherwise acceptance (and thereby the needed and wanted higher level of security) is jeopardized page 74 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 10 Single Sign On (SSO) One Time Authentification to get Access for the whole System Landscape Monitoring Monitoring Tool Set for performance, security, usage, capacities, connectors, errors, help desk,... Standard First and Best Practices standard connectors, best practice approaches for Identity Management Processes (IAM is not a unique selling point (USP)), not highly flexible customizing page 75 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Needed functionalities/characteristics of an IAM System p 11 Delegation standard functionality for Delegation of Access Rights without cascading only for a set of Access Rights considering Segregation of Duties (SoD)... Scalability concerning enrolled companies, applications, rules and policies,... Auditing Support by appropiate standard Reports, access rights for auditors,... etc. page 76 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Lessons Learnt & Critical Success Factors when Implementing IAM p1/4 Stepwise Approach and Implementation In an heterogeneous complex System landscape a big bang approach is a never ending – not successful story Prioritizations for connecting systems have to be made These Prios should be the base for rolling in and rolling out First of all: Process Design and Rules and Policies Do not start implementation before having designed the needed IAM Processes and the Rules and Policies If possible – take best practice experienced process and rule models (This should be delivered by the Solution Provider) page 77 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Lessons Learnt & Critical Success Factors when Implementing IAM p2/4 Clear Scoping Concentrate within an Implementation on the IAM needed Scope Remediation of Authorization Regulation in the Applications to be connected is not Prio 1 Maker transparent the scope. IAM Application Independance The IAM should be implemented on an and as an independant platform – it should not be part of an already running Application page 78 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Lessons Learnt & Critical Success Factors when Implementing IAM p3/4 Vendor selection Reserve enough time and ressources for Vendor Selection Preparation of a clear agreed criteria catalogue Prio 1: Standard Solutions and Best Practice Processes IAM is a cross application / IT needs Stakeholder Buy In For the Cross Application IAM certainly IT is a predestinated driver But the Business Buy In is a critical success factor – The project order has to come from the Group Board Support should come from Internal and External Auditing and Security Departments page 79 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Lessons Learnt & Critical Success Factors when Implementing IAM p4/4 Device Independency When rolling out IAM for an application it should be done independant from the used device and platform User-Focused Roll Out Try to avoid only technology driven breaks and inconsistencies – it should be understandable for the user... see more: Sailpoint: The 7 tenets of a successful Indetity and Access Management. White paper by Sailpoint, 2015 Gartner: How to Prevent the Most Common IAM Failures. Research by Gartner, 2014 page 80 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Upcoming and Exceeding Topics Interconnection between different companies – Non conflicting Accounts – non harmonized rules and policies – missing a global standard Meta IAM for IAM Connection to public / cloud applications Do we need (in future) Applications not managed by a central IAM (e. g. small non-critical application or highly critical applications)? How these application can use also the benefits of a central IAM System? … page 81 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Part 6: From Change to Run Go-Live is finished – what‘s to do? IT Infrastructure Library (ITIL) Change Management and Incident Management Service Level Agreements and Controls Global Support by a Globally Acting Team page 82 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Successfully „finished“ project Successful testing is done All Users are well trained All processes are updated and well documented All IT specifications are updated and well documented The IT system landscape is well prepared for start Migration and Cut Over are successfully done Change Management is completed: – Everybody is looking forward to making the first experiences with the new functionalities – Management and Sponsors are happy – …... Ready for GoLive... Is the project really successfully finished? page 83 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Preparation and Transition to the RUN Phase Already during the project phase and before GoLive: preparations for the Run Phase have to be done The transition phase – already starting before GoLive – is phase to manage the take over between a project organisation and the future or changed RUN organisation Implementation and/or Adapting RUN Organization and Run Processes Hypercare Phase – the phase after GoLive until final finishing and downing the project page 84 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary ITIL Service Management Processes – selected From: itSMF: An Introductory overview of ITIL V 3, p. 42 page 85 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Change Management Change Management vs. Change Management We have to differentiate: Change Management to manage the change for users and people (People Change Management - esp. needed during projects) Change Management to manage chnages in processes and IT system (IT Change Management as described in ITIL) page 86 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Additional preparations within the project Incident Management Knowledge Database for Knowledge Management Ticket Tool Help Desk Infrastructure Communication channels – One telephone number per country – One E-Mail adress – „Linking In“ for other help desk channels – Portal with Search and FAQ Tools – … Run people already part of the project – project people available for a certain period of time (hypercare …) page 87 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Service level Agreement (SLA) – p 1 (TO BE) SLA categories Examples of SLA elements Hours of Operation Hours that the service is available to users Hours reserved for planned downtime (maintenance) Amount of advance notice for network changes or other changes that may affect users Service Availability Percentage of time Application Services are running Percentage of time stores are mounted Percentage of time that other special services (e. g. Data Warehouse) are running System Performance Number of internal users that the application concurrently supports Number of remotely connected users that the application concurrently supports Number of transactions that are supported per unit of time Acceptable level of performance, such as latency experienced by users page 88 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Service level Agreement (SLA) - p 2 (TO BE) SLA categories Examples of SLA elements Disaster Recovery Amount of time allowed for recovery of each failure type, such as individual database failure, source code failure, site failure Amount of time it takes to provide a backup system so users can use the system functionalities with / without accessing historical data or other additional services Amount of time it takes to recover data to the point of failure Help Desk/Support Specific methods that users can use to contact the help desk Help desk response time for various classes of problems Help desk procedures regarding issue escalation procedures Other Amount of storage required per user Number of users who require special features, such as editing Master Data page 89 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Globally acting teams … … describe flexible groups of employees at different places, assembled on the basis of shared objectives or work assignments in order to ensure result orientation. Characterized by Independence of time and place High degree of virtuality Special focus on IT-network page 90 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Where are the differencies ? page 91 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Barriers of Globally Acting Teams + + Barriers due to different Technological Barriers due to organization, business processes barriers time, space, language and culture differences = „non-connected local teams“ Adapted from: Probst et al. 1997, p. 225 page 92 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Different Types of interaction … Collaboration Cooperation Coordination Information IT-Tools page 93 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Part 3: Integrated Service Delivery Process Roles – Shared Service Center Roles Implementing a Shared Service Center Running a Shared Service Center Future of Shared Service Centers System Complexity Interface Management page 94 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Integrated Service Delivery Finding and separating roles, which can be fulfilled – according to clear work instructions and – based on simple operating guidelines Such roles can be bundled in Shared Service Centers (SSC) In combination with standardization and globalization of processes these SSC‘s can be built on global or regional level One needed prerequisite: standardized IT Platforms And from the point of view for the customer: the service should be delivered as Integrated Service – without any differentiation between IT and Service page 95 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary HR Role Model HR Business Partners Discover Customer Intimacy HR Excellence Deliver Design Operational Excellence Efficiency HR Shared Services HR Centers of Expertise Design page 96 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Operating Model Tier 0 Employee and Tier 1 Manager Self- Tier 2 Service Generalist Tier 3 in Shared Service Specialist in Business Partner & Center All Employee Access Shared Service of Expertise Via Interactive Voice Response Business Partner: Defines HR strategies Specialist: to address business Generalist: Provides Provides complex solutions specific needs employee support, and transactions, admi- processes transactions, nisters policy, con- Center of Expertise: Knowledge Base handles FAQs and ducts in-depth Develops policy & and other ESS / conducts basic research, resolves issues process, expertise research support on request MSS Solutions accessed via Intranet page 97 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Implementing a Service Center: Integrated Service Delivery Customer view: He needs at least a Full Service He is interested in a clear Service Level Agreement It is irrelevant for him whether a task is performed by system or service agent No need to differ between Service and IT efforts – that is only a view of the delivering service units Delivery view Delivering a high quality Service for a minimum of efforts Always optimizing the part of IT and Services One and only one responsibility for IT and Service -> Delivering of an Integrated Service page 98 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Running a Service Center: Steering of Service Quality and Service Level Regular Service Level Controlling and Reporting Hard facts and soft facts Soft facts, e. g. by a sample testing directly within a call or via an E-Mail after ticket solved KPI’s can be Grade of satisfaction & Rate of return Number of Calls answered Ticket started Time of solving tickets (average or within the SLA-limits) Number of Problems (vs. Incident) System Downtimes Number of Portal Accesses As a Management Summary – always in the same design but highlighting “non-normal” figures and starting with 2 or 3 Super-Messages Separate KPI’s and more details for internal steering page 99 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Running a Service Center: Bench Marks Benchmarking of an Integrated Service Benchmarking only of Standardized Services High Country Dependency Do not benchmark exotic and Company specific Services Benchmark not only concerning costs but also concerning Quality Service Excellence Customer Satisfaction page 100 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Service Center – quo vadis? Economies and balance Improvement of existing Service Centers: Using economies of.. – Scope (more processes – but also less processes) – Scale (more countries and companies and people served) – Experiences of production (optimizing internal processes) and – Experiences of business (improving business processes) Getting the right (a better) balance – between Highly Tailored and Standard Solutions – highly diversified specialism mind and holistic concepts e. g. B- and C-Level Organisational Units e. g. Change and Run separation – Reporting Lines and specific assignments of attributes and employee groups – … page 101 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Complexity of systems Drivers of System Complexity Modifications of Standards Oversized Customizing Add-Ons and User-Exits Purpose- / customer-built specialities No standardization Complex and diversified Access Management High Integration vs. modular Architecture … and a high sophisticated Interface Landscape … page 102 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary … one measure for complexity reduction … Interface Management p 1 of 2 Frequent current situation system landscapes are getting more complex historical origin of interface models data redundancies and data conflicts data transfer without clear intended purpose cascading data transfer data interfaces are always process interfaces – synchronization needed data security and data privacy no or not sufficient documentation no clear data ownership / no clear maintenance ownership Several participating nets (user-net, service providers, IT providers, …) … page 103 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary … one measure for complexity reduction … Interface Management p 2 of 2 Remediation Measures Creating overview by installing an Interface Cadaster – Inbound, outbound – Purpose of data transfer and underlying process(es) – Data Owner and Responsible of receiving system – Frequency, Technique, Priority, Service Level – … Realization of Interface Policies – Consolidation (eliminating redundancies, only needed data, …) – Central Reporting Data Pool – Usage of standard Interfaces – no cascading – signed agreements – Encrypting of data – No data changes in the receiving system – … page 104 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary … one measure for complexity reduction … Interface Policy / Examples p 1 of 3 Reduce Complexity – Scope of data to be limited to current functional requirements of receiving system – Data must not be redistributed by receiving system – Data transformation and mapping logic (if necessary) should be implemented in the inbound interface Consolidate – Use standard interfaces (e.g. SAP iDoc technology) – Reuse interface for different receivers if appropriate – Use a standard data pool / data base page 105 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary … one measure for complexity reduction … Interface Policy / Examples p 2 of 3 Data owning system first / no data cascading – If data for interface can be delivered from the original data maintaining and owning system, the interface should be installed as outbound interface of this system Security – The receiving system has to assure the data security (access restriction, authorization management etc.) – Data transport has to be encrypted (e.g. https, FTPs) – Transportation Layer (XI/PI) may be used for data formatting, routing and transactional reliability Coordination of Change Management – Any changes in the sending/receiving system have to be checked if they have impact on interfaces page 106 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary … one measure for complexity reduction … Interface Policy / Examples p 3 of 3 No constraints in the receiving system – Constraints in the receiving system which lead to inbound filtering of data has to be EXPLICITLY handled in the sending system – e.g. the sending system allows multiple email-addresses, but the receiving system only allows one email address. Only two ways are allowed to resolve this a) The constraint is implemented in the sending system or one of the multiple email addresses is technically marked as the “principal email” which then is mapped to the outbound b) The constraint is removed in the receiving system – It is not allowed to implement filters in the inbound interface which are not assured by the data model of the sending system! Declaration of conformity by the receiving system … page 107 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary Thank you Contact: Consiliantibus GmbH Köln Karl-Albert Bebber Managing Director E-Mail: [email protected] Tel. +49 174 33 34 34 8 Rothenbacher Weg 31, 51503 Rösrath www.consiliantibus.com page 108 2024-06-15 / Karl-Albert Bebber MGLIIC – Lecture Summer Term 2024 Lectures Summary

Use Quizgecko on...
Browser
Browser