Sunday, July 27, 2008

Risks associated with business and IS/IT change

It is of value to review the data and/or procedures before and after making changes in business, IS/IT to avoid the following risks:

a. Reliance on systems or programs that are inaccurately processing data, processing inaccurate data, or both.

b. Unauthorized access to data that may result in destruction of data or improper changes to data, including the recording of unauthorized or nonexistent transactions or inaccurate recording of transactions.

c. Unauthorized changes to data in master files.

d. Unauthorized changes to systems or programs.

e. Failure to make necessary changes to systems or programs.

f. Inappropriate manual intervention.

g. Potential loss of data.

If we are to make change, to avoid those risks, have the surest way to succeed. The necessary information is to be considered. Thus it is not a good judgment to be in hurry to make change. Plan the action and make sure of it. Have a copy or backup of the data, systems and programs. If it is inevitable, wait until you can afford the risks involved.

Below is the site where the risks above were identified: http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=16274&TEMPLATE=/ContentManagement/ContentDisplay.cfm

Tuesday, July 22, 2008

Barriers in IS/IT

As I made a research, there were different informations that made me confused. Others did not convince me but one won my approval.
If we are to define barrier – it is something stopping progress or preventing approach. Easy to define and to spell but what really are the barriers in IS/IT?

Lack of current information for planning and developing technology
Lack of expertise in the use of information
Lack of international cooperation in developing the critical mass needed for projects and joint efforts.
Lack of interaction (lack of confidence and sometimes lack of information) between universities and industries


Studies developed new informations and strategies that are to be used for the development of technologies. These were conducted to help and attain these words – effective, easy and fast. So why not have those current informations and not just rely on the obsolete ones?

For the second spot, let me have an example as what I have understand. We have this word “information” and we are to create a sentence using that word. How can we create a sentence using that word if we, ourselves, do not know what the word means and how that word will be used that will suit to the sentence the way we deliver it? And how can we create a sentence if we just ignore it and don’t have the desire to know the definition of that word? If we are to connect, gathering, sharing, and knowing how to use those informations, contributes to the development of the IS/IT. In contrast, no development would happen.

For the third barrier, without participating in international affairs, current informations and technologies could be ignored. We could be emaciated from those new ideas and techniques, and we are refusing the help from those external source.

Communication is what the last spot trying to point out. When there is a communication, there can be understanding. Lack of communication could have done nothing at all.

The barriers in IS/IT were identified by this site: http://www.unm.edu/~jreenen/dlbook/chapter9.html






Thursday, July 17, 2008

Some best practices of IS/IT

There are 23 best practices within the information systems life cycle phases that were identified by the professionals in this site (http://www.portlandonline.com/auditor/index.cfm?a=13026&c=27102). Among those, I only chose ten.

These practices were identified to help stakeholders in managing an information systems software project. Each of these contributes to the success of the project. So why not learn these practices?

1. Determine if you have a project.
-Addressing the organization’s problems and deficiencies could help in easy building solutions. Member of the organization should be vigilant and should find ways to help the organization. Recommending projects is a great idea.

2. Try to keep projects small and modular.
-Ideal IS application architecture is easy to debug for error handling, for the improvement of the application for future use, and easy organization and evaluation. An application need not be complex. The design should suit to what the organization’s need.

3. Describe the project in functional terms.
-In creating a project, the functions of the system should be specified. These should be considered: how the application would work, what the expected outputs are, how the user would interact and what are the inputs, and other concepts.

4. Know your business processes.
-Understanding the business processes would lessen the inconsistencies. Before recommending a system, a study should be conducted on what are the different business processes and how does it run.

5. Evaluate the project financially.
-Identifying the projects costs and benefits is an important element to calculate if the project is worth doing.

6. Use project deliverables to define success.
-We keep on simulating a project without knowing the concepts, and without knowing what we are trying to work. Defining the criteria for project success helps the project stay on track and for evaluation of the project’s performance. Goals, objectives should be defined.

7. Involve users early and often.
-From the start, the users should be one of the concerns in creating a system. Every improvement, the user interface should be regarded. Important concerns that deals with the users’ expectations and needs.

8. If you need outside help, get it.
-If there is a need of the external help, the organization should seek help.

9. Negotiate a good contract.
-It is a need to negotiate a good contract for the equal profit between the organization and the vendor. Contracts are used for the formality of every transaction. And in case of inoperable systems, the vendor could react and for the organization to heed its dignity.

10. Don’t be afraid to stop and reevaluate if things are not going well.
-Though failures may occur, the work on the system should not stop. Just keep on going! If it seems like there is something wrong with the system, reevaluate. You may find the answers to your questions, and you may find better solutions.

Friday, July 11, 2008

Why Information Systems Fail


There are many reasons why IS/IT systems fails that caused so much trouble in any business. Based on the studies that were conducted, such failure is not caused by technological difficulties alone. We should also have to consider the problems regarding human resources and the functionality within a business.

As what I have studied, we could say that an IS fails when it does not meet its design objectives, excessive costs, missed deadlines, the users cannot interact well with the IS, and unable to meet the clients expectations. These are only some of the facts that correspond with the other observations. Though fail may occur, the work on the system should not stop. According to Sauer, actual failure finally and irreversibly occurs when a project organization is unable to sustain sufficient support to continue work on the system, including development, maintenance, and operation; and the cessation of work leaves users dissatisfied with what the system has done for them.

Other contributions why IS fails because it is not well planned, a study is not implemented, there are no specific goals, and inattention to the contribution of the staff’s character, coordination, knowledge, and performance in which they could have a good plan, and could come up with one great idea.

“You stop working because you fail… but you fail because you stop working.”