Summary Lectures LIS

Lecture1

What are information systems?- Systems to support people in their work

- Office functionality- Professional support- Transaction support- Support for business process management

Modelling theory- Models are abstractions from real world phenomena, developed for the purpose of reducing overall complexity- Models aggregate information and document only relevant aspects of the real world- Models are being developed in a specific modelling subject for a specific target audience with a specific modelling purpose in mind No right/wrong, but relevant/irrelevant model

Business processes- Collection of related events, activities and decisions, that involve a number of actors and object, and that collectively lead to an outcome that is of value to an organization or its customers

Processes and outcomes- Every process leads to one or several outcomes, positive or negative

- Positive outcomes deliver value- Negative outcomes reduce value

- Fault-to-resolution process’ outcomes 1. Fault repaired without technician intervention2. Fault repaired with minor technician intervention3. Fault repaired and fully covered by warranty4. Fault repaired and partly covered by warranty5. Fault repaired but not covered by warranty6. Fault not repaired (customer withdrew request)

The core elements of a process- Activities

- Active elements (e.g. ‘enter sales order’)

- Time-consuming, resource-demanding- State-changing

- Events- Passive elements (e.g. ‘sales order has been entered’) - Represent conditions/ circumstances- Atomic, instantaneous

- Business objects (or data)- The organizational artefacts that undergo state changes- Physical or electronic information- Examples; sales order, digital object, consulting proposal

- Actors (or resources)- The entities performing process activities and generating events- Human and systems- Examples (financial offices, warehouse clerk, ERP, CRM, SAP, ..)

How do we combine these?1. What needs be done and when? – Control flow2. What do we need to work on? – Data3. Who’s doing the work? – Resources (human& systems)

Process perspectives- Control flow perspective

- “what needs to be done and when”- Predecessor/ successor relationship among activities and events- The central information depicted in a process model

- Data perspective- “what do we need to work on”- Input/ output data to activities- Complements the control flow

- Resource perspective- “who’s doing the work?”- Human participants and systems that perform control flow activities and generate events- Complements the control flow

Further potential elements in a process- Objectives, goals

- Link to strategy- Risks

- For risk-profiling the strategy- Policies, Rules

- For checking process compliance- Knowledge

- To depict expertise required

Process modelling- Is a common language for naming and framing an issue- Integrates processes with other artefacts (e.g. systems, organisations, data, services, risks)- Enables walk-through, validation and testing (e.g. via simulation)- Can be used as a benchmark for measuring improvements – “what-if” analysis- Provides a blueprint for process automation

Why process modelling?- Business processes are increasingly valued as essential assets of an organisation- This significance demands dedicated management of processes- We need ways to extract processes out of the organisational complexity in order to discuss, analyse, improve and automate them

Lecture 2

What are transaction processing systems?- Systems to inform enterprises on relevant objects* Assets

- Goods, Machines, Buildings, etc.- Accounts receivable

* Liabilities- Accounts payable- Loans

* Employees* Business partners* Catalogue of items* Orders Systems to support process execution

Objects and object types- What are objects? Anything of interest for an organization

- Nouns, usually- Physical- Non-Physical

- Objects have attributes, which have values- Objects with the same attributes constitute a type- The relations between object types represent verbs- Objects types correspond to tables

- Objects correspond to rows in such a table- Attributes correspond to columns

Object types are modeled in UML Class Diagrams- Object type represented by box- Three horizontal parts

- Name of the object- Attributes- Methods (mainly to be skipped here)

Keys in relational (“tabular”) databases- Each table has a key – a unique attribute identifying each row (sometimes a unique set of attributes)- Each value of the key attribute may occur only once in this column of the table- Often, the key attribute of table A occurs also in table B- If so, it is calles a foreign key in table B. It is called the primary key of table A- Foreign keys lead to associations in the Class Diagram

-

State transition diagrams- Object types define the potential status of objects

- Change of objects = state transition diagrams- Status transitions correspond to people’s tasks

State transition diagrams and transaction processing systems- State-transitions are always transactions in TPS

- In designing transaction-processing systems, state-transitions play an important role- Create, read, update, Delete – CRUD

- So-called business logic check if transitions are allowed- A state-transition may trigger other actions, to be performed by business logic- Some transactions are trivial and therefore the state-transitions remain implicit

How to asses a TPS?* What is does = “functionality”- User support perform a task

- A task is: change an object or a set of related objects- Business logic rules which govern the work

- The core knowledge of a business- Data management- Authorization of performing tasks, applying the rules, managing the data* How it does this: “…..illities”- Scaleability, usability, portability, security..

In a layered architecture of TPS

Basis architecture TPS

How engineers build transaction processing systems- Define objects: e.g. order, material and customer- Provide a status notion to objects, and a life cycle- Define allowable states of the database- Define allowable state-transitions- Create software to support these- For transaction processing systems it is important how these object types are related to each other- This is described in a data model (Class Diagram)

Lecture 3

What is ERP?- Enterprise resource planning: integrates all departments and functions throughout an organization into a single IT system (or integrated set of IT systems) so that employess can make enterprise wide decisions by viewing enterprise wide information on all business operations- Standard software with much business knowledge

- Best practices of an industry pre-programmes- In the so-called business logic layer

- Highly parameterized Complex

Reasons ERP systems are powerful tools- ERP is a logical solution to separated applications- ERP addresses global information sharing and reporting- ERP avoids the pain and expense of fixing legacy systems

What is ERP

Core of ERP – one database- very important for logistics

Support of business processes via changing state of objects

From object models to TPS (engineers perspective)- Identify the business process- Derive business objects and their relations- Determine the life-cycles steps of objects

- Use state transition diagrams- In TPS these become the sessions

- Model the data and calculations needed to execute the state transitions (functionality)- In TPS, this becomes the business logic

- Identify the possible responsibilities to execute the sessions and access the data- In TPS, this becomes authorization

Warehousing and distribution

Some definitions- Shipper (“verlader”): a party who wants to transport goods

- Shipper often holds inventory in warehouses- Either third party warehouses or own warehouses

- Transporter (“vervoerder”): a party who provides transportation services. Only transportation?- Called “Wheels and Walls”.

- Logistics service provider: a party who provides transportation services and other services- Warehousing, quality control, packing, payment collecting, inventory management

(Physical) distribution- Distribution channels

- Regional warehouses who deliver to customers- Wholesale and retail

- Inventory management- Warehousing (Distribution center – DC)- Stock keeping units

- Transport- Material planning

Warehouse Management System (WMS) functionality- Inbound c.q. outbound (trucks)

- Allocating trucks to dock doors; sequencing of trucks- Prepare for unloading c.q. loading and quantity control

- Receiving (cargo)- Matching receipts from trucks with shipment advices

- Allocating to inspection areas and quality control- Cross docking (cargo)

- Transport order from receiving area to shipping door- Sequencing receipts, batching, sequencing shipments

- Storage (cargo)- Location control; FIFO/LIFO- Bulk vs. pick- from bulk to pick

- Shipping (cargo)- Picklist- Routing optimization

- Value adding activities- Packaging, testing, assembly

Transportation- Wheels and walls- Wheels – trips of trucks

- Or other means of transport- Cross docking may be included- Warehousing

Lecture 4

UML Class Diagrams- Object type: An set of similar objects about which we want to store data- Attributes: A single piece of information on an object type- Object: A specific occurrence of an object type- Types of relationships: cardinality

Different order types- Recall from UML practical

- Commercial orders (purchasing, sales, transport, service) usually have orderliness- This allows to order several items together in one delivery

- However, manufacturing order are usually intended for one final product- Sometimes a standard product in a certain lot size- At other times a customized product delivered by one organization, may also have a lot size- May consist of ready-to-assemble parts

- Customer, procurement, and production order go through stages- Received- Planned- Scheduled- Released- Delivered

Transaction processing approach- A transaction processing approach starts from the type of transaction (per object type- or per set object types)- A systems would ask a user (after logon):

- Which transactions do you want to handle? (Sessions in ERP)- E.g. credit check? Delivery? Quotations?

- The system would present a list of ‘enabled’ cases, and ask:- Which instance of the list of allowable cases do you want to work on?

- The system would support that the user is interested in executing transactions- Presumably by communicating with systems

- Activities are not carried out by humans only, but by man/machine systems

How to release a planned order- Is it necessary to store/save planned orders?- Is it worthwhile to store/save gross requirements

- For sure during the MRP-run- But planned orders are calculated qualities, therefore transaction processing is not meaningful- One exception: the release of a planned order- Goes with material allocations… of the components

Work order release – “what happens when?”

Lecture 5

Life cycles of objects or versions?- What is the life cycle of an item?

- Code number, not a physical product- A version is a new object, created from an existing object- Don’t confuse it with life-cycle, all objects have their own life cycle

Notion of progeny- Progeny: the notion that in the real world objects are created by using other objects- Geneology: the tracing back of an object’s ancestor(s)- What is the meaning of a version of a product items?

- A significant attribute value has been changed

What happens if a significant attribute changes?- If the product is interchangeable with respect to its external function, form and fit, a new version will be created. Otherwise a new identity (code number) will be created.- This is the Form, Fit, Function rule for product items in case of a significant attribute or property being changed

- If anything changes in FFF new code number- If nothing changes in FFF new version number

What is a significant attribute?- If the processes of manufacturing or maintenance of this product are affected by a change, then the attribute is significant- If the attribute is not significant (price, description, etc.) nothing will happen; version and code number will stay the same

Version vs. product identification number- A change in:

- The industrial engineering domain (form)- The design engineering domain (fit)- The requirements engineering domain (function)

All lead to a new product ID of the product involved

Disadvantages of a new id number:- Increased maintenance of data- A new code number may disconnect the relation between attribute values in the old code number and the new one- Increased complexity in obtaining historic information on usage, properties, sales and maintenance of the new product- If the old product occurs in paper document, it will be more difficult to relate this old product to it’s successors- Often, a successors has more functionality than it’s predecessor

Items and physical products differ- It is important to distinguish between the concepts of (product) item and (particular) physical product- An item is an information model of physical product- Items are e.g. found in catalogues of vendors of standard product. They are identified e.g. by product code number of RFID. The SKU concept refers to items. They are also traded by Amazon of Bol.com- Particular physical products are real-world objects with a location, owner, weight, dimensions. They may be identified by an item code, but there is often additional information which makes them unique.

Be careful:- A product item is model of a physical product- On other words; a document- When a parent item is deleted, there is no reason to delete the component- A particular physical product is different- Assembled particular physical product are uniquely identified in space and time, they have an owner, a history, etc.- They may be identified by an RFID- There components are other particular physical products- If the assembly is deleted, the components are deleted as well

Serialised items- Many physical product may belong to the same item- Such physical products may be identified individually

- E.g. 200 similar etches by an artist may be numbered- Good wines will individually identify bottles by a serial number- The same happens in airplane components

- An item is called a serialised item, if the individual physical products are identified individually

Lecture 6

ERP-implementation- ERP implementation is done to achieve some goal- Usually in the business- Creates therefore tension- ERP systems are made for transaction processing: robust, traceable, consistent, transparent- ERP systems are flexible… they have a huge number of parameters

- (and customer-specific code, foreseen/ supported by vendor)- Setting these parameters is a difficult job- Changing these parameters afterwards may cause problems with data and with people- Often, additional programming is required

- Not foreseen/ supported by the vendor- This may lead to problems when the system is upgraded- Upgrading involves normally migration

What is a project?- Unique- Clear start and finish- Separate budget- Own resources- Delivered to third party, etc.

What is a project? ERP project1. Scope Always large, cross functional;2. Products Many, and quite diverse;3. Stakeholders Many, diverging interest;4. Planning Long, much longer than usual in the industry;5. Milestones Not always many, but very complex;6. Dependencies Huge;7. Risks Many, not controlled by the project

What we learned from research- Karel Bakker- Risk management techniques are not effective because of the sophisticated way to identify, mitigate or control risks- But due to the fact that humans pay attention to risks, share expectations and commit to act

Implementation issues- (Ever increasing amount of) functionality- Scope and scope creep- Speed of implementation- Multiple stakeholders; conflicting interest- Project management goals versus business goals- New technologies

Experiences in the previous century:- Implementation of ERP as overall solution

- Register all ‘events’ (communication)- Make processes explicit- Define business knowledge

- From few professionals to many shared users- Breaking the silos down in organizations

- Create managerial control of costs, planning, turnover, profit- No clear definition of business objectives/ key performance indicatios & return on investment

Experiences nowadays:- ERP is only one application of a whole suite- Speedy implementation of ERP is crucial- Based on clear business targets

- Measurable PIs- Clear ROI, assigned to a person- Relatively small change

- ERP upgrade should fit in context: (business & IT) architecture

Why implement ERP?- Uniformity of information (same data everywhere)- All the business processes are linked together- Transparency, visibility and efficiency- Better profitability analyses- Clear expense control and monitoring- More accurate business forecasting

- Proper registration of commitments- Unit registration in planning and in actual figures

Advantages ERP- ‘Best practices’- Functional integration of business processes- Real time high quality shared information- Support for complex organisational structures- Flexible in growth- Low cost of software licenses- Uniform user interface

Disadvantages ERP- Upgrades and changes are expensive- Costs of application management also considerable- Common best of breed with all competitors- Version-dependent interfaces- Hard-coded logic- Niche players and new technologies for new business areas:

- CRM- APS- SRM- PDM- etc.

The ERP implementation project plan- Establish boundary conditions

- Scope, time, goals, costs, benefits, roles, actors, stakeholders- Create project organization

- Sponsor, team budget, baselines, communication, commitments, risks- High-level design:

- Key alternatives, business models, ICT organization, implementation sequence- Detailed design:

- Process models, organizational tasks, functionality to be (dis)activated, test plans

- SW Realization: - Parameter setting, customizations, training, migration plans & software, tests

- BPR:- Re-organize, set objectives, find PIs, define responsibilities, empower people

- SW Implementation: - Create CC, pilots, shadow runs, user feedback, migrate, go-life, archive, measure

Project organization- Steering committee : commitment from the top- Project team: sufficienly staffed, empowered, credible, representative, knowledgeble (B&ICT)- User involvement: key users, competence center, train the trainer concept- Clear scope and boundaries: is this a BPR project, an ICT project or both?- Roles of vendor and consultancy company as well as what the customer organization will do- Services: education, helpdesk, backup, testing, migration, documentation- Communication: who, what, when, why, how

Lessons learned – literature- Top management commitment essential

- Evergreen in management literature- In practice, a strong, empowered project team is crucial

- Early user involvement speeds up acceptance- What is early? More time leads to more change requests- Multi-site roll-out means multiple user-involvements- However …..

- Professional IT department guarantees success- Professional IT department seldom represents business- Techology-driven approach may be counter productive

Best practices- Be clear on goals- Don’t strive for perfection – the best is the enemy of the good- Contracting of roles after implementation should start early: vendor, consultant, competence center- Be very clear on the role and competencies to be developed of the competence center- First organize, than automate- Orchestrate allowable deviations from standard

- Always to sides of the coin present- Provide budgets for migration, testing and training

Bottlenecks- Clear goals

- make specific targets for every subproject- Top management support

- don’t expect employees to ‘do it alongside the daily things’, but hire extra capacity for ERP implementation or daily things

- Excellent project management- stick to the basic rules of good project management- professional program/ portfolio management

- Functionality- buy the ERP software as late as possible, keep switching costs low

- Customization (changes of the code)- choice of implementation partner is important- job interview with consultants of implementation partner- precise definition of specifications

- good test scenarios- Integration of systems

- good test scenarios- stick to the basic rules of good project management- professional program/ portfolio management

- Input of data- automatic check on correctness of data- project management on migration issues

ERP – three meanings- ERP standard package

- Artefact made by vendor- Has a life cycle- Different versions living next to each other

- ERP package configured- Artefact configured for customer- Different life cycle, but- A variant of the previous object- Single version

- Part of an organization, delivering information & services

ERP packages configuration- ERP packages as sold by vendors are like platforms

- These packages are configured when implemented in companies. ‘Configuration’ is a role for consultants.

- The packages are upgraded by vendors into new versions- Which have to be re-configured for implementations- New service pack (“version”) or new release (“new ID”)

- Packages can be changed when being implemented- Unchanged software is called: vanillaERP- Changed software is called: modifiedERP

ERP packages deployment and scope- ERP packages can be deployed in three ways

- On premise – own computing center – the classical way- Application service provider – remotely by ICT supplier- Software as a service – the new way – sharing software

- ERP packages have a certain scope- A set of modules = a set of functional departments- A set of processes - A single site- Multi-site- Multi-site, multi country

Lecture 7

ERP package configuration- ERP packages as sold by vendors are like platforms

- These packages are configured when implemented in companies. ‘Configuration is a role for consultants’

ERP packages upgrades- The packages are regularly upgraded by vendors – new service packs (versions) and new releases- Why?- There are minor changes and major changes- Minor = same set of parameters and data structure

- But new functionality- Major change

- Package has to be re-configured for new implementation- Data has to be migrated- User unlearn and retrain in the new package

ERP package integration- Implemented ERP packages are integrated with other packages such as office, PDM, warehousing, MES, SCM, …- The integration have to be re-inspected and sometimes redone when the package is upgraded

ERP package modification- Packages can be changed when being implemented

- Unchanged software is called: vanillaERP- Changed software is called: modifiedERP

Consequences:- Inspection and retesting for all minor upgrades- Plus reconfiguration and renewed modification for all major upgrades- Unless the modification is included in the new functionality

ERP packages deployment - ERP packages can be deployed in three ways

- On premise – own computing center – the classical way- Application service provider – remotely by ICT supplier- Software as a service – the new way – sharing software

- ASP- Creates economies of scale in application management - Backup and recovery, installing patches, helpdesk- Different users still have their own configuration, integration and modification

- SaaS- Creates additional economies of scale – only one instance of software running- No modification allowed, only different configurations

ERP scope- ERP packages have a certain scope

- A set of modules = a set of functional departments- A set of processes - A single site- Multi-site- Multi-site, multi country

Multi-site ERP- Logistics and finance become really complex in multi-site environments- The reason is, that all DSS, and functionality may have to specified per site- And business processes between sites should be supported- Therefore, the number of parameter settings and alternatives increases dramatically- Furthermore, supply chain planning is added – leading to Advanced Planning Systems

Deel 2 van het collegeEIS and ERP- The core EIS is transaction processing: support people in their work, meanwhile processing transactions for status monitoring of objects- Therefore information systems have three layers

1. Support the humans2. Execute business rules3. Store data

- These transaction-processing systems are often based on standard software – usually called ERP- There is more than ERP alone: CRM, business intelligence, APS, …

Planning with ERP- Planning with ERP goes via batch programmes- These are executed during the night, leading to plans in ERP- Output is integrated via Office and Mail with the workplace- Planning is well integrated with the remainder of ERP

Which kind of planning encountered in ERP- MRP

- Stock oriented- Time phased- Lot sizes and safety stocks- Backward from end-products to raw materials

- Master production schedule- Rough capacity planning- Demand forecasting- Drives the goodflow through factories and distribution- Not really machine scheduling

What are Advanced Planning Systems?- Almost interactive: response in seconds (due to: in-ram technology)- Sometimes: multi-use systems- Advanced graphical user interfaces- Mathematical optimization possible- That is: many solutions taken into account- The best being preserved

Important:- APS is based on different technology than ERP- This technology requires (specialist) knowledge- APS is often delivered by another vendor- APS has another goal than ERP: planning versus transaction processing- Implementation of software often leads to new requirements- Innovative companies change by definition all the time

Why different technology- Strength of ERP: transaction processing- Data-oriented- Algorithmic calculations require a snapshot of the database- Cannot be made while transaction processing proceeds- Inherently slow, because record access requires milliseconds- APS emplys in-Ram technology (microseconds)

How about combination of APS and ERP?- Pro:

- Interactive planning- Optimizing

- Con- Complex technology- Computation just a bit different from ERP- Different data models- Complex data transformation- Not only from ERP to APS, but also vice versa

Complex for SMEs