New Post has been published on techZavia
New Post has been published on http://www.techzavia.com/the-information-systems-management-framework/
The Information Systems Management Framework
For the Support and Development of Enterprise Applications in Education.
There is always a lot of talk about designing and implementing an IT or ICT Strategy in educational organisations, and rightly so. However it still leaves an applications manager with the task to define the strategy for developing, supporting and maintaining information systems and applications. In this article an Information Systems Management Framework for supporting and developing Enterprise Applicaitons is being discussed.
Why a Framework is Needed?
A framework for IS Management is needed to create a model for managing enterprise applications. Although there are some IS Architecture Frameworks available, this one was developed as a management framework for educational organisations in UK.
The goal is to create a holistic view of managing information systems and especially managing enterprise applications and to answer the question “How to do it?”, rather than what to do. “What to do?” could be answered through creating a services catalogue, but this is not in the context of the IS Management Framework right now, so the activities and drivers are not discussed as yet, but may be incorporated in future revisions. It is assumed that the two main categories of IS team would be Support and Development of the business applications. This could also include managing web applications and corporate website in some organisations. Nevertheless a clear definition of all of its existing components should be established in order to have a clear view of the development and support work.
Also note that in the framework, development is considered part of the support activity so the words development and support are often used interchangeably. These terms shall be defined separately in order to distinguish between them when necessary.
Components of the IS Management Framework
The context of managing information systems is quite vast and could include issues like security, governance, maintenance of the life cycle of the applications and so on. But this framework focuses on three areas or dimensions of the system in order to get us going. These three areas which form the main components of the IS Management Framework are:
Two types of goals need to be discussed and established.
The external goals are set for the different department and business areas of the organisation, e.g. Finance, HR, Marketing, and Registry. All these departments need IS to help them in achieving their goals. However we need to clearly identify which exact external goals are we helping with. Let’s say Finance could have a goal to improve savings by 5%. Then we can help them in developing reporting functions to monitor their costs and expenditure to achieve this. But probably not all of their goals could be taken directly by us to support. Many times we have to re-define external goals in the context of IS to help achieving them.
In IS, we could have our own goals e.g. in terms of improving quality like quality of systems, quality of information and quality of governance. Or perhaps we could have goals to integrate systems, build and maintain data warehouses, develop business intelligence, or develop either ourselves or help other departments developing their reporting functions while providing them with analytical tools to do so, and so on. Our performance reviews should reflect on both external and internal goals.
Once the goals are set, the strategies to achieve those goals are developed. The IS Management Framework provides a four step approach towards designing strategies. One major advantage of creating a simple 4-Steps strategy, as discussed below, is that it is easier to communicate it with users in order to develop a consensus towards tasks prioritisation. For example, instead of saying that any server issues will be dealt first and then the desktop ones, it is easier and more effective to say that any system stability issues will be dealt first.
For developing integrated systems and providing support for enterprise applications, a 4-Steps approach is as following:
These steps could involve different activities as shown in the figure.
Most of the support or development work by an IS or Applications department is spend in stabilising the systems. Also further steps in this 4-Steps approach are not possible to take when the stability of the system is under threat. However a clear definition of a stabilised environment should be established and agreed upon to help towards providing efficient support. It could be one of the following, or more:
All these above could represent infrastructural, application, or data level stability concerns. For example, system could be either the Physical Servers or the Database Systems, or the security systems implemented on hardware level. Processes could be either Server side processes, Database processes, Web Services or the desktop processes. Performance of different components of an application or the infrastructure where the application is residing could be a concern. For example, we used to have severe performance issues while running some application processes that were affecting web services up to an extent that most users were not able to use web services at all at certain times. These needed to be resolved as a top priority and a lot of resources were utilised to sort the performance issues.
Practices are often not seen as a stability threatening issue by many, but could be the issue especially in the organisations where practices are not formalised and standardised, or where there documentation of the formal process does not take place.
Once a system or application is fairly stabilised, we need to work on developing technical standards that could be implemented in various settings within IS and even outside of IS if possible, e.g. in other areas of IT. For example in one instance, a software documentation template was standardised and was adopted by web development team.
Standardisation techniques are well known and any of them could be adopted depending on situation. However there could be three things that can help in developing standardisation.
The context of the areas for standardisation should be established and planned. Also the context of the data needs to be understood, for example the same column name in different systems could be totally different in terms of value, data type, or even meaning. The documentation needs to be done and updated to help in establishing standard activities and the data.
Automating processes could help different and disparate systems and applications to standardise their data and processes. Many times, certain data which is mandatory for one system in specific settings is not important for another system, e.g. a valid email address of an applicant could be non-essential for students system, but if this data is being fed from students system into finance system, it could be essential for finance system if they decide not to print invoices for environmental reasons. This means that a valid email address has to be created and is to be populated in both students and finance systems and then students system. All these ifs and buts need to be considered by IS when developing automated processes or when integrating different systems.
The word globalise here is used in the context of integration. Although developing methods or systems that move data from one system to another is useful, integrating systems is much more beneficial. The globalisation or the integration of the different applications is a very challenging job indeed. We need to have resources to buy integration tools, expertise available to understand different systems and most importantly a good understanding of what we want to achieve with integration. Development of business intelligence and analysis tools, and more comprehensive reporting could be achieved through globalisation of the data.
Integrating systems could be done in various ways and using various tools, but one thing that needs to be considered is that when sometimes a full integration is not possible, may be due to resource constraints, then at least the different systems could be exposed to other systems, let’s say using views or functions to bring data. For example, on one occasion, certain views were created in finance system to expose some data from HR systems to create some on-the-fly reports. These views eliminated the standard process of generating monthly spread sheets from HR system and then manually entering them in Finance and then using that data on some other finance reports.
Once systems and practices are globalised or integrated, a more useful reporting function could be developed based on a global view of data coming from various systems and giving a more complete picture of the business. The reporting system could be in the form of standard reports or analytical tools that are developed by IS or third party vendors, that use the global/integrated data, may be through a data warehouse.
Also note that the framework uses a two head arrow between Globalise and Maximise. If it is not possible to globalise/integrate systems or develop a data warehouse for some reasons like resource or time constraints, at least the available systems should be maximised in terms of their usefulness. It could be their performance, or the reporting functions or the data entry functions etc. Sometimes this could be achieved through simply automating complex tasks. For example in one case, a student sanctions process was automated hence eliminating a lots of paper work or relying on individuals to make decisions.
After the goals and strategies are set, the next issues to think about are the function of the support teams and how to carry out this function, in other words defining the attitude or the customer service policy that the teams would adopt to carry out the function.
Function: Control Systems
One obvious function of a support team is to control or manage the systems or the applications. However many times, it is not very obvious that what would be the extent of it and where the lines will be drawn. This is because the involvement of different types of support teams outside of an applications support department, e.g. Server Support, Network Support, Desktop Support, or the support within the functional departments who own the system. System ownership could be a conflicting issue itself, so a roles and responsibility document should be created to create a collaborative environment.
If support teams do not fully control the system on a whole, then at least they need to control certain defined and agreed upon parts of it. For example, let’s say that administration of the Windows Servers on which the database systems are residing should be controlled by Server Team, the database administration could be controlled by either server team or a database administration team, application support should be managed by applications team and the user administration of the application (like SITS users or Planon users) could be either fully controlled by finance admin team or maybe shared between IS applications support and finance admin teams.
Sometimes neglected, but a very important aspect of providing support service is defining the attitude. Attitudes mostly come naturally as part of the personality of a support team either individually or as a collective character. Defining the extant of the attitudes is important. It not only defines a customer service policy, it also helps in decision making as discussed below. There are 4 Cs of Customer Services that need to be defined and then refine through reviews in order to improve them and build a strong culture of provided quality customer service.
Commitment means how far a team is willing to go to solve problems.
Does a team’s commitment reflect organisational values?
Is team committed to internal goals or to external goals, where is the balance?
Commitment is about a team’s willingness to provide service in an agreed upon time and closure.
It is about fulfilling promises within time and within budget.
Communications within team, with other team teams, and with users is a very aspect of support.
Modes of communications are important to think about i.e. how to communicate and also how much to communicate.
Acknowledge, even before sorting the problem, so that the person knows that the team is on the case.
Clarifying the problem with the user, before delegating it to other teams is very important and actually methods like work flows could be developed to achieve this.
The speed and timing of communication is also a very important factor to consider.
Appropriately narrowing down the audience of a particular communications is also an important factor to consider.
Under-promising and over-delivering is better than the other way around.
It’s about working efficiently and build working relationships and teams.
What will be the extent and scope of the cooperation between team members among themselves and with other support teams?
How much are we willing to give? Is it about give and take or does it remain one-sided? How much are we genuinely willing to give?
Is giving favours part of our job, or our nature, or do we have some goals to achieve e.g. building positive relationships?
Can we evolve cooperation into collaboration?
To understand that the person I am trying to help is just doing his/her job.
It’s about going an extra mile. It starts where cooperation ends.
It’s about empathy. It is to understand that we are not hired to become overnight heroes (heroines) but we are hired to help and support others with their needs. Helping others is part of the job, not an added bonus in the service process.
It’s much more than about users using the applications that we are supporting. It’s about making them comfortable with them and also with our service. We must build confidence in them that we’ll be there for them when a need will arise.
3. Operational & User Management
Operational and user management is defined so that the activities could be categorised. This can help in keeping focus for different members of the IS team to their respective areas of responsibilities.The managers supervising the operations need to think about lots of issues.
The framework needs them to consider the following as priority, though these priorities could be changed depending on strategies defined previously and situation.
1. Understand Business needs
Understanding of the ever changing business needs is a continuous process and underpins the decision making. Even designing strategies and their application depends on the context and scope of business needs. Understanding business needs means creating a business view and a world view in which the organisation exists.
When we are support multiple applications, there are times when we have to decide which particular issue to give preference to over others. Sometimes we have to give preference to a particular application depending on a number of factors that could be categorised as following:
A Combination of both technical and non-technical factors
Technical factors could be like the failing or under-performing systems, user accounts management issues, or if the problem we are trying to resolve regardless of its nature, require us to develop a technical solution to solve it.
Non-Technical factors could be like the political power of the users of a particular system that forces a team to give them a preference over others regardless of the severity of the issues.
A combination of technical and non-technical factors are when an issue technical or not, has an impact on the business processes or indirect or direct effects on major client groups, requires us to solve through a combination of technical and non-technical measures like creating reports that are then used to make decisions. For example, a series of processes in different systems updating sanctions of the students who have paid but were not processed timely due to the timing of these processes and not because of the failure of them, will have a negative impact and could become politicised. We’ll need to create reports to monitor these processes e.g. reconciliation reports to find any discrepancies in the data. Creating of process, changing their timing and creating reports are technical issues, but monitoring the reports or making decisions based on them are non-technical from support team’s point of view.
Regular review of strategies and tactics is important, probably on par with the performance reviews because performance is perhaps easier to manage using management methods like motivation, however it is much more difficult to adjust to the changing business needs, the cotemporary situations both internally and externally to the support teams or even to the organisation itself. The frequency of the reviews should be flexible and could depend on the timing of the application of the strategies, or may be on the milestone events for the organisation, e.g. students’ enrolment periods, semesters, performance reviews, etc.
User Management means creating a collaborative approach towards supporting users. User needs must be at the heart of designing any IS strategies and internal/external processes. The user management means the day-to-day dealing with the users. All lines of support must make users their top priority. But user management means empowerment to both user and support staff for taking actions and making decisions, as long as they are within the limits of the business needs. It’s difficult to draw lines sometimes and that is why user management not easy. This also includes building good relationship with users, identifying training needs that is in scope of IS, e.g. using MS Excel add-ins for generating finance reports, writing SQL within an Excel report to get data from a database, using Business Objects Reporting, creating web pages for respective departments through EasySite, etc.
The primary job of support and development is to provide solutions to the day-to-day problems. A thought process should be developed to think about the challenges on all steps shown in the 4-Steps strategy and solutions should be developed to address all the issues related to each layer. This requires a very proactive approach to providing solutions because a lot of development should be done to minimise support issues related to lower steps in the 4-steps. The idea is to shift the focus of the support team from providing support to providing development. In this context, support means actions that are taken to fix broken components of the systems, and development means the actions to improve the systems.
As the diagram is showing the relationship between active support and development & monitoring. A problematic system requires more support than development and support teams have to spend more time in stabilising the system. On the other hand, for mature systems, there is more focus on developmental activities rather than support. Hence this idea that focus of support teams should be changed from fixing problems to development.
Prioritising the tasks according to the 4-Steps approach or as appropriate to the business/user needs is a challenging issue that we face in applications support every day. It is imperative that the tasks are prioritised using a criteria that is agreed with users or at least with key users/decision makers. The emphasis should be on the quality of service and quickly solving problems rather than getting into a number game, because the number of issues sorted is mostly irrelevant to users. A common sense approach is essential to be successful in prioritising tasks. 4-Step approach could be a starting point towards building a consensus on tasks prioritisation.
Implications of IS Management Framework
The IS Management Framework has the following implications:
It was developed in Educational Institutions in UK (FE and HE), both public and private, so it assumes the structure of the Information Systems or the applications departments would be as in an educational institute. Many other organisations like NHS could have somewhat similar structure, however many could differ.
It covers the management of team(s) supporting applications. It aims to provide a simple approach towards developing strategy on departmental level hence a 4-Steps approach. This approach basically tries to broadly categorise different problems in order to provide guidance towards developing a consensus on the prioritisation of tasks. Teams will still have to decide which problem lies under which category. Also it does not say that you have to spend more time to stabilise the system or that you cannot solve standardisation or integrations issues before others. Different issues could be taken and sorted simultaneously if systems allow that, so there is no limitation on that as such.
It does not provide an in-depth description of the functions and activities of IS/Applications teams. But it aims to provide a starting point for defining functions of teams.
The Information Systems Management Framework was developed over a number of years. It provides an insight into some crucial aspects of the management of applications or the information systems department. It can be used to build bespoke models, e.g. by defining your own goals, strategies or criteria for prioritisation and customer service.
References and Further Reading
The framework was developed through an evolutionary process over a number of years. The figure representing the framework itself was inspired by ICAEW’s Finance Function Framework that was consulted in 2012 much after the development of ISA Management framework back in 2007. The link to that is as follows:
http://www.icaew.com/~/media/Files/Technical/Business-and-financial-management/finance-direction/finance-function-a-framework-for-analysis.pdf
Some other useful links to understand information systems frameworks (active on 9/01/2013):
http://www.ismg.ac.uk/Home.aspx
http://www.authorstream.com/Presentation/aSGuest7394-125449-information-systems-framework-business-finance-ppt-powerpoint/
Note: IS Management Framework has been developed by By Waqas Ahmad.
