Generic Business Intelligence Business Benefits

May 28th, 2012

As a result of implementing business intelligence platforms, businesses and organisations gain value in a number of different functions, ranging from simple cost avoidance, to competitive advantage by creating faster and more timely availability of information to drive or automate decisions:

  1. Eliminate the need for users to extract and make personal or local versions of reports.
  2. Leverage important and valuable data currently being captured by ERP, CRM, SCM and other systems, that may not have the native capability to add value internally.
  3. Standardise the organisations output, to reduce the impact of employee turnover and loss of local knowledge
  4. Reduce the need for training by unlocking islands of information stored in Excel spreadsheets
  5. Improve the integrity of analytics by assuring source data validity and calculation integrity, reducing or eliminating the cost of business decisions based on incorrect data. Assuming that proper change control and scenarios are designed and in place.
  6. Enable information to drive automation within the organisations decision making. i.e. high turnover in stock been ordered to meet minimum volumes based upon availability and item turnover.
  7. Better meet financial reporting and regulatory compliance by assuring consistency of information and automating analysis, validation and distribution of reports by policy.

Why Process Map?

May 26th, 2012

It is important to understand how various functions and process handle and manage through to customer delivery. The best way to represent this is using a business process map. Process maps are an effective way to identify constraints, bottlenecks, duplications and areas of re-work. In complex processes with many interactions it is highly unlikely that a single person will understand the entire process, it is even more unlikely that that person can offer an unbiased view of the customer experience. Process maps should represent the total number of steps, players and quantities involved in delivering a process or output.

Is Change Management actually a job? Can you actually manage change? Does manage change imply a reactive function rather than leading it?

May 23rd, 2012

You, as IT leaders and shakers can make change happen, you can plan the events, you can react to external factors forcing change upon you. But do you actually “manage” it? Can you?

In reality when you break down those “changes” into processes, functions and detail, you’re influencing or seeking approval to introduce new methods or pushing tasks onto other people who have no direct reporting relationship to yourself. Therefore I ask you, are you making a change or are you simply a conductor indicating and directing a change.

In reality you’re a leader, directing the change, creating tasks and objectives for others to follow and initiate. Why pretend to manage change as if it’s a reactive activity admit you’re actually the conductor, controlling and directing Organisational changes.

Now for the kicker… does change ever stop, can you define what “changed” is? Should your change agents simply move on, have they successfully re-engineered the environment so they aren’t needed or have they transformed the role into something different? Do those transformed individuals stop moving goal posts, who is continuing to review outputs and make improvements?

High Level Design (HLD) Vs. Low Level Design (LLD)

May 23rd, 2012

For people who have been involved in software projects, they will constantly hear the terms, High Level Design (HLD) and Low Level Design (LLD). So what are the differences between these 2 design stages and when are they respectively used ?

High Level Design (HLD) gives the overall System Design in terms of Functional Architecture and Database design. It designs the over all architecture of the entire system from main module to all sub module. This is very useful for the developers to understand the flow of the system. In this phase design team, review team (testers) and customers plays a major role. For this the entry criteria are the requirement document that is SRS. And the exit criteria will be HLD, projects standards, the functional design documents, and the database design document. Further, High level deign gives the overview of the development of product. In other words how the program is going to be divided into functions, modules, subdivision etc.

Low Level Design (LLD) During the detailed phase, the view of the application developed during the high level design is broken down into modules and programs. Logic design is done for every program and then documented as program specifications. For every program, a unit test plan is created. The entry criteria for this will be the HLD document. And the exit criteria will the program specification and unit test plan (LLD).

The Low Level Design Document gives the design of the actual program code which is designed based on the High Level Design Document. It defines Internal logic of corresponding submodule designers are preparing and mapping individual LLD’s to Every module. A good Low Level Design Document developed will make the program very easy to be developed by developers because if proper analysis is made and the Low Level Design Document is prepared then the code can be developed by developers directly from Low Level Design Document with minimal effort of debugging and testing.

What is Cloud Computing?

April 22nd, 2012

Cloud computing is a computing model, where resources such as computing power, storage, network and software are abstracted and provided as services across the Internet remotely accessible.

Billing models for these services are generally similar to the ones adopted for utilities and paid for on a per use basis. On-demand availability, ease of provisioning, dynamic and virtually infinite scalability are some of the key attributes of cloud computing.

An infrastructure setup using the cloud computing model is generally referred to as the “cloud”. The following are the broad categories of services available on the cloud:

• Infrastructure as a Service (IaaS)

• Platform as a Service (PaaS)

• Software as a Service (SaaS)

Amazon Web Services (AWS) is one of the major players providing IaaS. AWS have two popular services – Elastic Compute Cloud (EC2) and Simple Storage Service (S3), available through web services.

Cloud Computing can be put to some very dynamic uses, much like many web-based applications, controls and interactions between the host device and user can have many differing abstract layers.

Consumers with the advent of smartphones and services like Apple, Amazon, Google allowing mass on-line storage for media to consumers are becoming very aware of how easy and readily available these applications are becoming. Other companies like dropbox offer similar Infrastructure options to consumers. Many smartphone applications operate a SaaS whereby data is synchronised with the application owners own private/public cloud.

What many consumers know where there data ends up?

How do you protect yourself from losing control of your data?

How do you backup and maintain your own data in the age of the cloud?

Modular Designing Documents

April 6th, 2012

Modular Designing Documents, which are is primafaciely done by the Technical Persons of the Implementation Team like Technical Project Leads / Project Manager. These documents are the Design Documents, which is again based on the BR 120 – Business Requirement Gathering as provided by the business.

These MD’s are of basically discussed any customization needs or any special behaviaour oracle system should work which is not the Standard Oracle Funtionality. These also discussed about the tables and the Interface Tables or forms which are going to be used in the particular modules. Thses also discussed about the High Level Designs like Flows of the Business and all.

These MD’s are basically made after you all Functional Design and if there is no work around Oracle System provides for a particular Test Scenario and there is no other way other than to go for the Customization.

Now I suppose you can understand what is the basic difference between these two.

Now as a Funtional Consultant you need to always go for the BR – 100, that is set up doc. and in your scenario ( as you said that you have created in GL – COA / CAL / CVR etc) you have to document all these into BR 100.

The first version of the BR100 will probably be used to build the TEST environment. Any changes required as a result of problems encountered will be incorporated into the next version of the BR100, which will then be used to build (say) the UAT environment. In parallel with these environments, there will probably be a DEVELOPMENT environment and it may be that there will be changes required to the BR100 because of issues encountered there. The “Final” version of the BR100 will probably then be used to build both the PRODUCTION and TRAINING environments.

Business Requirement Documents

April 6th, 2012

Business Requirement Documents, areis primafaciely done by the Functional Persons of the Implementation Team like Funtional Project Leads / Managers. These documents are the Set up Documents, which is 100% based on the BR 120 – Business Requirement Gatherings as provided by the business.

You can say these are As Is process. So BR 100 is the To Be Process after you gather all sorts of info from the Biz and map in the Oracle Systems.

Oracle AIM Document Names

April 6th, 2012

Business Process Architecture (BP)
BP.010 Define Business and Process Strategy
BP.020 Catalogue and Analyze Potential Changes
BP.030 Determine Data Gathering Requirements
BP.040 Develop Current Process Model
BP.050 Review Leading Practices
BP.060 Develop High-Level Process Vision
BP.070 Develop High-Level Process Design
BP.080 Develop Future Process Model
BP.090 Document Business Procedure

Business Requirements Definition (RD)
RD.010 Identify Current Financial and Operating Structure
RD.020 Conduct Current Business Baseline
RD.030 Establish Process and Mapping Summary
RD.040 Gather Business Volumes and Metrics
RD.050 Gather Business Requirements
RD.060 Determine Audit and Control Requirements
RD.070 Identify Business Availability Requirements
RD.080 Identify Reporting and Information Access Requirements

Business Requirements Mapping
BR.010 Analyze High-Level Gaps
BR.020 Prepare mapping environment
BR.030 Map Business requirements
BR.040 Map Business Data
BR.050 Conduct Integration Fit Analysis
BR.060 Create Information Model
BR.070 Create Reporting Fit Analysis
BR.080 Test Business Solutions
BR.090 Confirm Integrated Business Solutions
BR.100 Define Applications Setup
BR.110 Define security Profiles

Application and Technical Architecture (TA)
TA.010 Define Architecture Requirements and Strategy
TA.020 Identify Current Technical Architecture
TA.030 Develop Preliminary Conceptual Architecture
TA.040 Define Application Architecture
TA.050 Define System Availability Strategy
TA.060 Define Reporting and Information Access Strategy
TA.070 Revise Conceptual Architecture
TA.080 Define Application Security Architecture
TA.090 Define Application and Database Server Architecture
TA.100 Define and Propose Architecture Subsystems
TA.110 Define System Capacity Plan
TA.120 Define Platform and Network Architecture
TA.130 Define Application Deployment Plan
TA.140 Assess Performance Risks
TA.150 Define System Management Procedures

Module Design and Build (MD)
MD.010 Define Application Extension Strategy
MD.020 Define and estimate application extensions
MD.030 Define design standards
MD.040 Define Build Standards
MD.050 Create Application extensions functional design
MD.060 Design Database extensions
MD.070 Create Application extensions technical design
MD.080 Review functional and Technical designs
MD.090 Prepare Development environment
MD.100 Create Database extensions
MD.110 Create Application extension modules
MD.120 Create Installation routines

Data Conversion (CV)
CV.010 Define data conversion requirements and strategy
CV.020 Define Conversion standards
CV.030 Prepare conversion environment
CV.040 Perform conversion data mapping
CV.050 Define manual conversion procedures
CV.060 Design conversion programs
CV.070 Prepare conversion test plans
CV.080 Develop conversion programs
CV.090 Perform conversion unit tests
CV.100 Perform conversion business objects
CV.110 Perform conversion validation tests
CV.120 Install conversion programs
CV.130 Convert and verify data

Documentation (DO)
DO.010 Define documentation requirements and strategy
DO.020 Define Documentation standards and procedures
DO.030 Prepare glossary
DO.040 Prepare documentation environment
DO.050 Produce documentation prototypes and templates
DO.060 Publish user reference manual
DO.070 Publish user guide
DO.080 Publish technical reference manual
DO.090 Publish system management guide

Business System Testing (TE)
TE.010 Define testing requirements and strategy
TE.020 Develop unit test script
TE.030 Develop link test script
TE.040 Develop system test script
TE.050 Develop systems integration test script
TE.060 Prepare testing environments
TE.070 Perform unit test
TE.080 Perform link test
TE.090 perform installation test
TE.100 Prepare key users for testing
TE.110 Perform system test
TE.120 Perform systems integration test
TE.130 Perform Acceptance test

PERFORMACE TESTING (PT)
PT.010 – Define Performance Testing Strategy
PT.020 – Identify Performance Test Scenarios
PT.030 – Identify Performance Test Transaction
PT.040 – Create Performance Test Scripts
PT.050 – Design Performance Test Transaction Programs
PT.060 – Design Performance Test Data
PT.070 – Design Test Database Load Programs
PT.080 – Create Performance Test Transaction Programs
PT.090 – Create Test Database Load Programs
PT.100 – Construct Performance Test Database
PT.110 – Prepare Performance Test Environment
PT.120 – Execute Performance Test

Adoption and Learning (AP)
AP.010 – Define Executive Project Strategy
AP.020 – Conduct Initial Project Team Orientation
AP.030 – Develop Project Team Learning Plan
AP.040 – Prepare Project Team Learning Environment
AP.050 – Conduct Project Team Learning Events
AP.060 – Develop Business Unit Managers Readiness Plan
AP.070 – Develop Project Readiness Roadmap
AP.080 – Develop and Execute Communication Campaign
AP.090 – Develop Managers’ Readiness Plan
AP.100 – Identify Business Process Impact on Organization
AP.110 – Align Human Performance Support Systems
AP.120 – Align Information Technology Groups
AP.130 – Conduct User Learning Needs Analysis
AP.140 – Develop User Learning Plan
AP.150 – Develop User Learningware
AP.160 – Prepare User Learning Environment
AP.170 – Conduct User Learning Events
AP.180 – Conduct Effectiveness Assessment

Production Migration (PM)
PM.010 – Define Transition Strategy
PM.020 – Design Production Support Infrastructure
PM.030 – Develop Transition and Contingency Plan
PM.040 – Prepare Production Environment
PM.050 – Set Up Applications
PM.060 – Implement Production Support Infrastructure
PM.070 – Verify Production Readiness
PM.080 – Begin Production
PM.090 – Measure System Performance
PM.100 – Maintain System
PM.110 – Refine Production System
PM.120 – Decommission Former Systems
PM.130 – Propose Future Business Direction
PM.140 – Propose Future Technical Direction

For Sale: Ex-MOD Bunker

December 30th, 2011

Praticalities aside, the idea of having my own bunker has fasinated me.

If Britain had been attacked by a nuclear bomb during the Cold War, its government would have survived by retreating to a massive, 35-acre complex buried beneath the county of Wiltshire. I call it a bunker in the headline, but it was more like a small town—large rooms linked by roads, built on the site of an abandoned quarry. Known as Burlington, it could house 4000 people and feed them all for 3 months. It was also home a broadcasting studio and hospital.

Considering the size and space, it may make for an interesting site, suggetions:

1) Film Studio: Problems: Access and movement of materials into the site

2) Massive Server Farm: Cooling and Elextricity – Big Plus – Very secure.

3) Umbrella Research base – Possibility of creating the T-Virus… a few of you might get where that was going.

the Namibian: Metal ball from space falls in Omusati Region

December 25th, 2011

the Namibian: Metal ball from space falls in Omusati Region.

Space Junk? Really, someone has got to have lost this thing.