General discussion


What is an information system

By mark ·

Typically one thinks of an information system as being the internal management system such as the ordering system, the payment system, resource management system etc. that the company uses. A good example is an ERP (Enterprise Resource Planning) system which deals with the whole supply chain. (See a later section for a definition / description of an ERP).

Although this is true it is also limiting since, there is generally not one IT system and second, the IT systems are not the only information systems that a business uses. The IT systems can therefore be best defined as the formal information systems. There are however, also the informal or non-structured information systems. These are typically the verbal systems, the satellite IT systems and the external systems. See wikipaedia for a further definition. While these systems are not the formal ones and the formal ones are often the known backbone of an organisation, a business information system should be understood to include the people networks too.

Why? Make no mistake, it is not sufficient to implement an accounting system and expect a company to run. Although this may seem obvious, the fact that people need to communicate and need systems, methods, and channels to do so is not always considered. So a business information system should also include the escalation and delegation channels such as regular team or board meetings and the communiqu?s that issue from them, notice-boards, email systems, intranets, document sharing sites, the internet etc.

What to do about this?

One approach is simply to be aware of the different systems in play. However what happens in the time of crisis, when people leave and suddenly productivity drops? One notices that information holders are crucial. What is the solution to this? Insist on information sharing? Prohibit information retention? or build an information system which incites, encourages, rewards information sharing and helps people to understand that information is the life-blood of an organisation.

So how to do this? Focus on tools, on methods, on training, brainstorming, cooperation or goodwill? All these things. This is where it is crucial to understand that company attitude is crucial to the functioning or dis-functioning of a company information system.

First a typical information system. While there is no "typical" information system as such since all organisations are unique. The example is given to demonstrate the idea of what we see as a typical system such as a simple purchasing and sales system.

The aim here is to contrast with the wider information system which not only includes the formal management system and satellite IT systems but also informal networks and systems. The key here is to understand that these systems, whether vital or not, formalised or not, do exist and have an effect, directly or indirectly on business operations. This topic is examined further later.

A more concrete approach may be to examine in the short term the various formal IT systems. This is certainly easier, because their functionality can be or may already be documented through technical analysis. An appraisal can be made of where functionality overlaps and a plan made to build a new all-encompassing system (or consciously remove or do without some functionality)

What is information systems architecture and how does one go about it?

Simply put, the approach here is twofold. One is to formalise the documentation of formal systems. This means ensuring that existing functionality and procedures are written down so that the information system remains "known" despite the coming and going over time of different people. (It useful to ensure in your quality system that this documentation is managed and at the very least updated when changes are made)

Second, the approach is to document (formally) the informal systems. Does this seem like a paradox? Not necessarily. Formal documentation of informal systems means, generally using a formal methodology (notation) to document informal systems. And in the best case to use the same notation for both formal and informal systems. Why? Simply to be able create one single top level overview of the company information system.

Using a methodology.

Why use a methodology, what is the added value of a methodology and why not do something else? The answer is simple. First we aim to use, as much as possible, a graphical tool. Although a clich?, it still rings true that a picture speaks a thousand words. This is true for information systems design more than ever, since systems are more complex than ever. Second, a graphical tool has codes which mean the same thing throughout. In UML (as above) a little man means an actor (either human or systemic) and an oval means a use case. In SSADM, boxes mean processes and so on. The point here is consistency. When a symbol is used it means the same thing everywhere and links between symbols mean that things interact in the same way.

This all means one thing; clarity and readability. And this is essential when documenting and when communicating the sense of things. When I send my documentation to others or it is consulted, it is more easily understood. (rem interviewing techniques; where when a question is asked, the interviewee is asked to repeat what they have understood). The same difficulty occurs here: reducing ambiguity saves time.


Ok well that's all well and good but what is the point? The point is that with a vision of what an information system is, what information is used in the organisation, what the difference is with just the formal systems, what the impact and presence of informal systems has on operations one can determine whether both the formal systems are adequate, whether the informal systems function "properly" and even whether some of the informal systems can be or should be formalised in whole or in part.

To do this accurately and cost effectively, documentation (formalisation) is required, especially when using external contractors or consultants. Indeed, why use external contractors? Because it is rare that an internal manager has the time, the mandate, the motivation to effect such an analysis and because quite often this type of work requires specialist skills.

Why is documentation required? To enable discussion, debate and decision making. Documentation, while useful to store for reference, is most useful when talking. And what are we talking about here? How an organisation functions, how it can be improved, where savings can be made and productivity improved, how lives and processes can be made smoother and easier and, the bottom line, how to make more profit, of course.

All this may smack of business process re-engineering and other like buzzwords of the past. And it is. But that's no reason to ignore it and its no reason not to do it and we don't necessarily need another buzzword. However, what is important is to focus on operations, efficiency, improvement by eliminating duplication, rework, inefficiency and by reducing business reactivity through efficient system processing.

This conversation is currently closed to new comments.

39 total posts (Page 2 of 4)   Prev   01 | 02 | 03 | 04   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -

Now I understand your topic.

by CharlieSpencer In reply to A discussion [forum]

My opinion is that it's nearly impossible for IT to account for what happens outside established procedures. You can't accomodate what you don't know exists. Either the informal processes must be documented and incorporated into the standard flow or information, or management must ensure information flow conforms to the existing standards. I believe the first option is the better one; usually the reason people work 'outside the system' is because the systemic methods aren't sufficient to allow the to perform their job.

Collapse -

Informal systems

by mark In reply to Now I understand your top ...

Interesting. But I'm not not talking about disfunctioning systems but functioning ones. Indeed they may function very well, they are just informal but undocumented and therefore (but not necessarily) unknown to management. They might also be called "the people" and the way they work. Formalising them is not to change them and not necessarily to bring them in to the mainstream, even though this option exists, but just to understand how they function.

Putting it another way, on a slightly different tack, we spend a lot of IT money bringing satellite systems into the single central system and often for good reasons. But if we leave them outside the main one and just understand them, they may be able to continue to function properly.

Collapse -

You asked.

by santeewelding In reply to Your a sarcastic lot aren ...

And you answered your own question.

The oldest one I'm aware of in this context is,

1. Tell 'em what you're gonna tell them

2. Tell 'em

3. Tell 'em what you told them.

You did that in your three points, and rather well, I think.

Otherwise, the body of your text resembles German philosophical or American sociological garbage. Or, what passes for IT.

Collapse -

Philosophical garbage?

by mark In reply to You asked.

Is philosophical = garbage. Is sociology = garbage? And who defines IT and what is and what is not? It is also about management, analysis and people or are you restricting it to coding and machines?

P.S. Perhaps the summary would have sufficed. And perhaps we could get off to a better footing by talking around that.

Collapse -

Less is more

by jdclyde In reply to Philosophical garbage?

The more text you throw at someone, the less they will read. That is the first thing you should have learned in school.

Short and sweet, get right to the point.

Follow up with supporting information as needed and where required.

Good luck with that.


Collapse -

More or Less

by mark In reply to Less is more

I did learn to pr?cis ...

Collapse -

Welcome, Mark

by Tig2 In reply to Philosophical garbage?

First- as a poor screen reader, I don't know that I really
absorbed the ideas that you were trying to present. I
agree with you that a summary form would have sufficed.

Long content is generally reserved for blogs and becomes
linked to the discussion it generates. This way people can
choose to read the blog or not and still contribute to the
discussion. In general, blogs stay between 600 and 1000
words so that the reader can stay engaged with the topic
and not be frustrated by reading the screen. It also helps
us to fit better with the average consumer on the site.
Many prefer to skim the content and will read fully only if
there is interest.

I hope that we haven't chased you away. I look forward to
reading more from you.

Collapse -

Blogs and forums

by mark In reply to Welcome, Mark

Thanks. I guess due to the reactions I got that that seems about right; blogs for longer stuff and forums for byte sized (or bite-sized) chunks with references.

For reference see for more philosophical sociological European garbage (I paraphrase another commentator !!)

Collapse -


by Tig2 In reply to Blogs and forums

Thanks for posting the link! I will look forward to reading

I personally tend to enjoy philosophical sociological European

Collapse -


by LarryD4 In reply to Excellent!


Thanks Tiggs for making me laugh..

Back to Networks Forum
39 total posts (Page 2 of 4)   Prev   01 | 02 | 03 | 04   Next

Related Discussions

Related Forums