A excellent post i found  for sap best practice, it requires Market place access though. Wealth of information for people who are new to SAP arena.

SAP Best Practice ‘Business Scenarios’ address implementation of the SAP Enterprise Portal from the perspective that a business has certain goals and objectives it needs to accomplish. SAP Best Practices for Enterprise Portal’s goal is to leverage the portal to support these business goals and objectives, by using basic portal functionality and integrating other SAP and non-SAP solutions where required.

To implement each SAP Best Practices business scenario listed in the “Scenario Installation Table” on this page, you must implement a series of building blocks according to the scenarios documentation. The size and content of the blocks can vary from simple technical functions, to more complex functions that can be used as standalone solution elements.

For detailed information and documentation on the installation procedure of each scenario, review the the table to the right. Each link brings you to a scenario description. Additionally, you will find the technical information related to the scenario along with its business process procedure and a list of the building blocks required to run the scenario.

How to get started:

1. To implement a scenario, choose the link for the scenario from the list on this table.
2. Review the scenario’s description to see if it meets your requirements, and then choose the Scenario Installation Guide in scenario’s document list.
3. Then, simply follow the instructions in the Scenario Installation Guide. This document will lead you through the complete implementation of the scenario, and point you to the necessary building blocks when required.

Note:

All SAP Best Practices for Enterprise Portal scenarios can combined with other SAP Best Practices solutions.  If your company would like to integrate other SAP Solutions into your landscape quickly, but don’t yet have them configured, review other SAP Best Practices solutions for an accelerated pilot, or implementation starting point.

Relevant SAP Best Practices solutions include:

• SAP Best Practices for CRM
• SAP Best Practices for Business Intelligence (based on SAP BW)
• SAP Best Practices for Baseline (based on SAP R/3)
• SAP Best Practice for HCM
• and more…

For more information, please refer to SAP Service Marketplace at http://service.sap.com/bestpractices for more information.

·         Take this time to set the stage for your particular mySAP project in terms of Solution Vision, SAP components to be implemented, business drivers, project timelines, key milestones, and other project-specific data.

·         Determine whether this new SAP component to be sized is being integrated with an existing SAP landscape, replacing a current system, or simply refreshing a current system. If vendors have little direction in this regard, then the resulting sizings will probably be so different as to be incomparable.

·         Review the numbers you have shared through your RFI, Questionnaires, or Quick Sizer output, and make sure that everyone understands your definition of what the term “user” means to you.

·         Clearly identify your priorities in regard to the following[md]TCO, performance, availability, scalability, and manageability. Giving your hardware vendors this kind of insight helps to avoid huge surprises when you finally receive their version of what you need in terms of an SAP solution sizing.

·         Discuss your system architecture and other technology biases, including whether you prefer a central system approach to a more distributed architecture, whether you are biased for or against a particular Operating System or database product, and so on. You should also share what hardware, OS, and database platforms your current enterprise software solutions depend upon.

·         Along these same lines, be sure to share the skillsets and experience you already have in-house with regard to various hardware, OS, and DB platforms, and how likely you are to change or accept something new.

·         Discuss your views and thoughts with regard to risk: Are you willing to try something brand new, or reasonably new, if the potential rewards are great? Do you tend to favor a conservative approach to solution sizing, or something perhaps more innovative or leading-edge?

·         Identify which SAP system landscape components must absolutely be sized (like Development, Test, and Production), and which might be “in the air” (like a Business Sandbox, Technical Sandbox, Training system, and so on). Include whether you prefer the same platforms and components across these systems (a high level of standardization), or whether initial budget constraints require a different approach. The more details the better.

·         Similarly, address the sizing of each database for each system landscape component.

·         If scalability was not previously covered in detail, indicate something as to the scalability that the system must provide. For example, does your company intend to grow or shrink significantly through acquisitions, mergers, or divestitures over the next 12-36 months?

·         In terms of accessibility and front-end desktop or laptop requirements, will Internet access be required? What about new desktops or other client devices?

·         If certain vendors have already been selected, I think it makes sense to share this information as well. For example, as a hardware vendor with excellent relationships with a number of the “Big 4,” I like to hear about whether an SAP consulting organization has already been selected to do the functional work of implementation. Similarly, it’s helpful to understand which systems integrators, if any, have already been selected, or whether a certain database or Operating System vendor has already been given the nod.

·         You also need to discuss any plans for stress-testing, and any thoughts you might have on proof-of-concept exercises. Every now and then, at little to no cost, you can leverage an SAP technology partner to actually “prove” that his solution operates as advertised. This is more often the case with new SAP Solution Stack alternatives that a particular technology partner is anxious to “get into production” for the sake of selling more of the same solutions down the road. In example, I’ve been involved with POCs related to proving the scalability of new hardware platforms and different database products.

·         Open up the call at this point for questions. Usually, questions involve clarifying why or how you completed the questions in various SAP sizing questionnaires, or clarification of data provided in your RFI.

·         I believe that it makes sense to end the call with a synopsis of everything that has been discussed, and a specific date by which you expect all solution sizings in your inbox, along with reiterating what you perceive to be the greatest risk in your SAP project plan. This latter point serves to remind all of the participants on the call how important your SAP project is to your business, and therefore should underscore the importance that each vendor places in his solution sizing efforts. Follow up these words with a written 1-2 page document shared via email.

Before any sizing begins, a conference call between the SAP customer and various SAP technology partners (sizing partners) is very helpful – by determining the answers to the following questions, the sizing engineers greatly improve their chances of architecting a mySAP solution “right” the first time, and thus avoid or minimize subsequent and time-consuming re-sizings. The sizing engineer should ask the following:

• Why are you implementing SAP?

(business reasons will impact HA and other considerations)

• Are you interested in a low cost/maximum value solution?

(price sensitivity will drive platforms)

• Is overall performance/response time the driving factor behind the configuration?

(max performing disk subsystem/RAID configuration, more application servers)

• Is overall availability of the system critical or simply ‘important’ – how many nines of availability are you looking for?

(HA and DR considerations)

• Does your company anticipate growing/shrinking via acquisitions/mergers/divestitures soon?

(impacts role/potential for scalability in the solution, or the ability to easily redeploy assets if no longer needed)

• Are you biased towards one OS over another (i.e. W2K or a specific version of UNIX)?

• Are you biased towards a particular database/RDBMS? (Oracle, SQL Server, DB2, etc)?

• Are you biased towards a particular hardware vendor (HP, IBM, other)?
• Do you want the ‘latest and greatest’ hardware? (technology perspective – hot plug RAM or PCI, support for the fastest processors with the most cache, platforms that support the most RAM, 64 bit architectures, etc) Why?

• Do you want the ‘latest and greatest’ database release? Why?

(risk vs potential for improved performance or latest HA options)

• Do you want the ‘latest and greatest’ OS release? Why?

(risk vs potential for improved performance or latest HA options)

• What level of expertise do you have in regards to implementing and supporting SAP?

(will drive specifying a solution stack with which the company is familiar)

• Do you understand the role, or need, a ‘Technical Sandbox’ specified for your SAP system landscape?

• What about a ‘Training’ system earmarked for end-users? Other specialty systems?

• Will you want to provide Internet browser-based access to the system to be sized?

• Will you be implementing another mySAP.com component shortly after this system?

(might drive adoption of platforms with a longer life cycle)

• Who has been selected as your systems integration partner (SI) and functional partner?

(may drive platform, based on their expertise or core competencies)

• Who is your hardware reseller, or are you buying direct?

(indicated price-sensitivity and to some extent partners, and therefore competencies)

• Are there any vertical industry solutions expected to be implemented as part of your mySAP solution? Which ones?

(this drives core sizing in terms of CPU, RAM, and disk requirements)

• What do you perceive to be the greatest risk in implementing this SAP system?

• Will you be stress-testing the proposed solution prior to Go-Live? Why/why not?

(drives “super-sizing” of, or building additional overall capacity into, the solution)

Types of Project Management for SAP Projects

• 1. Project Integration Management coordinating all other phases, and managing the five project process groups – Initiate, Plan, Execute, Control, & Close). Focus on Project Plan development, execution, and overall change control:

1)       Project Definition (specific task, start/end dates, why this project is unique)

2)       Key risks – List of Constraints (limit options) and Assumptions (assumed to be true)

3)       Description of the ‘Project Plan Methodology’ to be used (i.e. hard tools like the PM software and specific charts, etc., and soft tools like kick-off meetings & status-review mtgs)

4)       List of Stakeholders (client) and their skills/knowledge

5)       PMIS – Project Management Information System, tools and techniques used to gather. Integrate, and disseminate outputs of the other PM phases

6)       Project Plan Execution – most of the budget is consumed here. Identify what it is.

7)       Overall Change Control – identify how change will be managed and coordinated, given that it will affect cost, risk, quality, scope, and schedule/staffing. Outputs from Change Control include Lessons Learned, Corrective Action, and the actual project plan updates.

8)       Project Plan Development results in the PROJECT PLAN, which consists of:

a)       Project Charter & most of the above

b)       Scope Statement

c)       WBS – Work Breakdown Structure, including cost estimates, scheduled start dates, and naming who is responsible for each  WBS task (responsibility assignment)

d)       Performance measurement baselines for schedule and cost

e)       Major Milestones, and target dates for each

f)        Key or required staff

g)       Open issues & Pending Decisions

h)       Might also include a ‘Project Organization Chart’ in large projects

SAP System Landscape Best Practices and Rules of Thumb

Infrastructure/Network/Domain Best Practices

·         A separate domain for all W2K-based SAP resources is recommended by both SAP and its technology partners (primarily for security purposes, as this minimizes the number of people that have administrator access and can thus disable or change the SAP Services or purposely/inadvertently delete SAP/database disk partitions). This also serves to keep extraneous network/domain-related traffic off of the Enterprise SAP domain.

·         It is also recommended that separate subnets be deployed for the production SAP system and all other SAP systems.

·         Further,  in 3-tier configurations, the traffic between the Database Server and Application Server(s) should reside on a separate high-speed (i.e. 100 Mbit/sec or GigE) subnet, hence the need for at least TWO NICs in each Application Server – one NIC supports this back-end network, and the other NIC supports the public network used by the SAPGUI/WebGUI clients.

·         For standardization purposes, these NICs should be IDENTICAL.

General Server Considerations

·         Only servers and Disk Subsystems (including disk controller/disk storage combinations) specifically certified to support SAP may be proposed (though once a controller has been certified in a particular vendor’s platform, it’s certified for all platforms).

·         More recently, SAP has left the Disk Subsystem certification up to the hardware vendor.

·         All volumes (OS/Pagefile, DB & SAP executables, and Log Files), except possibly the database volume(s), should ALWAYS be configured for Hardware Level RAID 1. Database volumes may be configured for any number of RAID levels, depending upon performance, availability, redundancy, and other requirements.

·         All database volumes should be configured with a “Hot Spare” so as to minimize the potential for losing yet another drive, and therefore losing data.

·         Pagefiles and Swap partitions are typically configured per SAP’s recommendation of 4 times physical RAM (this actually varies, depending upon the specific Basis release and component being deployed). However, greater than a 10 GB Pagefile/Swap is virtually pointless, as the SAP formula does not apply well beyond a certain memory footprint.

·         Hardware vendors should never propose systems that exceed 65% expected CPU utilization. In fact, many hardware partners size for 33% CPU load, keeping another 33% to address peaks or batch loads, and the remaining 34% for emergencies/high seasonal peaks.

Tape Backup/Restore/Basic DR Strategy Best Practices

·         The Tape Solution specified for the Landscape should be standardized around a single density (or backward-compatible to other densities in the Landscape), i.e. only 35/70 GB DLT drives will be configured. Of course, this does not preclude use of different hardware tape subsystems – perhaps a DLT Tape Array might be deployed for Production, and a shared Tape Library might be utilized by all other systems, for example.

·         For the best level of protection, two tape drives should be used for Production – a separate tape drive should be used to backup database LOGS, and another one used for database volume backups. This maximizes the potential for successful backups/restores, as it protects against tape drive problems that lead to corrupt media.

·         Regardless of physical devices, different tape cartridges must be used to backup the logs and the database, again to ensure that the database can be restored – this protects against tape media failure.

·         Network-based BACKUP/RESTORE servers are typically only recommended if a dedicated Gigabit network link is implemented. Thus, we would now need 3 discrete NICs in a 3-tier solution. The reason for the 3^rd NIC is simple – potential bottlenecks associated with network-based 100Mbit or slower networks, especially shared networks. It’s preferred to go with SAN-based technology if your budget allows this, as described next.

·         The SAN Switched Fabric/Fibre-Channel based Tape Library keep backup/restore traffic off of other networks. In the case of a SAN, a dedicated piece of gear is required to connect the SAN to the tape library. As for FCAL systems, a dedicated 7 or 12-port Fibre Hub is necessary. Note that many legacy 7-port Fibre Hubs are not “manageable,” though. On the other hand, not all 12-port FCAL hubs supported Microsoft clusters. So do your homework in this regard – you may lean one way or the other, for standardization, capability, or other purposes.

SAP Server Pre-Installation Checklist
(HW and OS only)

Verify Basic Data Center Infrastructure Installation

___1. Ensure that all server/disk subsystem racks are physically installed.
___2. Ensure that all servers/disk shelves are physically installed.
___3. Verify that all PCI and other controller cards occupy a “standard” PCI or other slot in each server (for example, all public NICs should reside in slot x, and all HBAs for external SAN connections should reside in y and z).
___4. Ensure that all SAN disks are physically installed.
___5. Ensure that all SAN cabinets are cabled to SAN Switches, and all SAN Switches are cabled to redundant HBAs in each Database or other SAN-attached server.
___6. Ensure SAN disks are to be carved into volumes consistent with your SAP Competency Center’s recommendations.
___7. Ensure that all servers are cabled via 10BaseT CAT5 to redundant network switches (as dictated by the solution sizing or HW requirements).
___8. Verify that the public and private (and cluster interconnect, if applicable) network connections are clearly labeled and ready.
___9. Verify that all HOSTNAMES and IP addresses (including management appliance or similar IP addresses) have been determined and documented in advance of actually installing OS’s.

General Power and HA Power Requirements
___1. All racks should be configured with redundant PDU’s.
___2. All servers, disk subsystems, and network equipment should be installed with redundant power supplies.
___3. Each power supply should be connected to different PDU’s.
___4. Each PDU should be connected to a separate UPS (preferred) or power source.
___5. Ensure that all power is laid out as required, L6-30P for servers and L6-20P for SAN/Disk subsystems (verify specifics with your hardware partner).

Update HW configuration (as required)

___1. Perform all firmware (FW) upgrades prior to configuring any drives at a hardware level – upgrade all array controller(s), drives, and system boards to versions/release levels approved by the hardware vendor and your SAP Competency Center.
___2. Assume 4+ drives are installed in each server – typically, 1 drive is mirrored to another, for two mirror-sets total. Check with your SAP Competency Center or solution sizing for specifics.
___3. Carve the local disks. Start the Array Configuration Utility or equivalent to verify configuration of local server drives
___4. Create 2 arrays, 1st drive mirrored to 2nd, 3rd drive mirrored to 4th.
___5. Ensure that a hot spare is set up, if room is available for another drive.
___6. Unless specific testing has been performed that indicates another configuration is better, go with all array controller default values. For example, ensure that read/write cache is set to 50/50.
___7. Create 1 logical drive per array (do not create more than one logical drive per array unless directed to do so per the sizing).

Update OS (assumes W2KAS/SPx currently installed)

___1. Verify that the base W2KAS OS load has been performed, and that the currently supported service packs/patches have been applied)
___2. Choose a SAP system name consistent with your naming standards. The NAME must NOT exceed 13 characters in most cases (SAP limitations), though this varies. Since other applications are still limited to 8 characters, the best way to go is to choose a name that does not exceed 8 characters but still manages to reflect the role of the server.
___3. Create the admin/installation user (i.e. r3padm, verify the name with the SAP Basis team) – MUST BE lowercase – and give this user domain admin (or admin) rights – note that ALL SAP installations, updates, and administration activities need to be performed with this user ID.
___4. Ensure that all LOCAL drives are formatted for NTFS (explorer, select root, file, properties, general tab), 64kb recommended for log and data files, 4kb or 8kb recommended for all others.
___5. For INTERNAL drives only (to be used for OS and pagefile), depending on the physical drive size, you may wish to create 2, 3, or more drives on each physical array. For example, with 18 GB drives, 3 drives of about 6GB is common. Be consistent across all servers.
___6. Label all disk drive volumes, i.e. – C: OS, D: UTIL, E: PAGE1, F: PAGE2, G: PAGE3, H: PAGE4, Z: CDROM, or equivalent (as per standards)
___7. Set the TEMP environment variable (control panel, system) – used by R3setup.bat or other installation processes, which will be executed later by the SAP Basis team.
___8. Create the C:\TEMP directory if it doesn’t exist already.
___9. Perform Pagefile sizing – 4x physical RAM, 10 GB max OK unless directed otherwise (may wish to round up just to be consistent).
___10. Configure pagefiles via Control Panel, System) – suggest 4095 MB on drives C:, E:, F: – refer to the standard Pagefile sizing developed for customer’s EA environment.
___11. Modify the default ‘Server’ service property – change it to ‘Maximize Throughput for Network Applications’ (this changes how memory/cache is allocated, and is set via network & connection places, properties, pick connection, properties, file and print sharing, properties)
___12. Grant ‘everyone’ permissions to root/all subdirectories of all logical drives
___13. Ensure your hardware specific driver-overlays are up to date, and approved by the hardware vendor’s SAP Competency Center. For example, it’s common to load special network, array, and management drivers that replace the default W2K drivers.
___14. Load the SNMP service (W2K) if not loaded already– note that service packs and other updates/patches may need to be reapplied.
___15. Load any solution stack management agents not already loaded, as directed by the SAP Basis team.
___16. Check the W2K Event Viewer for issues
___17. Check the Management Console for issues
___18. Select a 3-character SID (system ID), consistent with Customer’s EA naming standards.
___19. Set up an alias for SAPTRANSHOST in the HOSTS file – edit C:\WINNT\SYSTEM32\DRIVERS\ETC, and add an entry for SAPTRANSHOST to point to the particular system’s central instance.
___20. Verify that Internet Explorer is at version 5.x.
___21. OPTIONAL – after the ENTIRE SAP INSTALLATION, go back to Control Panel, System, Performance, and change ‘foreground’ to ‘background’ – this ensures that a locally logged-on user does not rob the logged-in SAP R/3 clients of their otherwise entitled memory/processor cycles. You may also wish to load any array configuration or management utilities locally on the server, too, to facilitate future change control/troubleshooting.

Prepare for the DB and R/3 installation

___1. Read through the pertinent INSTALLATION guide (InstGuide – print it, make it easy on yourself!) and the standard SAP product guide (may be found on CD with the installation kit)
___2. Request that the SAP Basis team obtain any pertinent SAP Notes – see the InstGuide for a list of pertinent notes, and read these – they may impact the basic setup of the server/infrastructure.

SAP Server Pre-Installation Checklist (HW and OS only)

Verify Basic Data Center Infrastructure Installation

1. Ensure that all server/disk subsystem racks are physically installed.

2. Ensure that all servers/disk shelves are physically installed.

3. Verify that all PCI and other controller cards occupy a “standard” PCI or other slot in each server (for example, all public NICs should reside in slot x, and all HBAs for external SAN connections should reside in y and z).

4. Ensure that all SAN disks are physically installed.

5. Ensure that all SAN cabinets are cabled to SAN Switches, and all SAN Switches are cabled to redundant HBAs in each Database or other SAN-attached server.

6. Ensure SAN disks are to be carved into volumes consistent with your SAP Competency Center’s recommendations.

7. Ensure that all servers are cabled via 10BaseT CAT5 to redundant network switches (as dictated by the solution sizing or HW requirements).

8. Verify that the public and private (and cluster interconnect, if applicable) network connections are clearly labeled and ready.

9. Verify that all HOSTNAMES and IP addresses (including management appliance or similar IP addresses) have been determined and documented in advance of actually installing OS’s.

General Power and HA Power Requirements

1. All racks should be configured with redundant PDU’s.

2. All servers, disk subsystems, and network equipment should be installed with redundant power supplies.

3. Each power supply should be connected to different PDU’s.

4. Each PDU should be connected to a separate UPS (preferred) or power source.

5. Ensure that all power is laid out as required, L6-30P for servers and L6-20P for SAN/Disk subsystems (verify specifics with your hardware partner).

Update HW configuration (as required)

1. Perform all firmware (FW) upgrades prior to configuring any drives at a hardware level – upgrade all array controller(s), drives, and system boards to versions/release levels approved by the hardware vendor and your SAP Competency Center.

2. Assume 4+ drives are installed in each server – typically, 1 drive is mirrored to another, for two mirror-sets total. Check with your SAP Competency Center or solution sizing for specifics.

3. Carve the local disks. Start the Array Configuration Utility or equivalent to verify configuration of local server drives

4. Create 2 arrays, 1st drive mirrored to 2nd, 3rd drive mirrored to 4th.

5. Ensure that a hot spare is set up, if room is available for another drive.

6. Unless specific testing has been performed that indicates another configuration is better, go with all array controller default values. For example, ensure that read/write cache is set to 50/50.

7. Create 1 logical drive per array (do not create more than one logical drive per array unless directed to do so per the sizing).

Update OS (assumes W2KAS/SPx currently installed)

1. Verify that the base W2KAS OS load has been performed, and that the currently supported service packs/patches have been applied)

2. Choose a SAP system name consistent with your naming standards. The NAME must NOT exceed 13 characters in most cases (SAP limitations), though this varies. Since other applications are still limited to 8 characters, the best way to go is to choose a name that does not exceed 8 characters but still manages to reflect the role of the server.

3. Create the admin/installation user (i.e. r3padm, verify the name with the SAP Basis team) – MUST BE lowercase – and give this user domain admin (or admin) rights – note that ALL SAP installations, updates, and administration activities need to be performed with this user ID.

4. Ensure that all LOCAL drives are formatted for NTFS (explorer, select root, file, properties, general tab), 64kb recommended for log and data files, 4kb or 8kb recommended for all others.

5. For INTERNAL drives only (to be used for OS and pagefile), depending on the physical drive size, you may wish to create 2, 3, or more drives on each physical array. For example, with 18 GB drives, 3 drives of about 6GB is common. Be consistent across all servers.

6. Label all disk drive volumes, i.e. – C: OS, D: UTIL, E: PAGE1, F: PAGE2, G: PAGE3, H: PAGE4, Z: CDROM, or equivalent (as per standards)

7. Set the TEMP environment variable (control panel, system) – used by R3setup.bat or other installation processes, which will be executed later by the SAP Basis team.

8. Create the C:\TEMP directory if it doesn’t exist already.

9. Perform Pagefile sizing – 4x physical RAM, 10 GB max OK unless directed otherwise (may wish to round up just to be consistent).

10. Configure pagefiles via Control Panel, System) – suggest 4095 MB on drives C:, E:, F: – refer to the standard Pagefile sizing developed for customer’s EA environment.

11. Modify the default ‘Server’ service property – change it to ‘Maximize Throughput for Network Applications’ (this changes how memory/cache is allocated, and is set via network & connection places, properties, pick connection, properties, file and print sharing, properties)

12. Grant ‘everyone’ permissions to root/all subdirectories of all logical drives

13. Ensure your hardware specific driver-overlays are up to date, and approved by the hardware vendor’s SAP Competency Center. For example, it’s common to load special network, array, and management drivers that replace the default W2K drivers.

14. Load the SNMP service (W2K) if not loaded already- note that service packs and other updates/patches may need to be reapplied.

15. Load any solution stack management agents not already loaded, as directed by the SAP Basis team.

16. Check the W2K Event Viewer for issues

17. Check the Management Console for issues

18. Select a 3-character SID (system ID), consistent with Customer’s EA naming standards.

19. Set up an alias for SAPTRANSHOST in the HOSTS file – edit C:\WINNT\SYSTEM32\DRIVERS\ETC, and add an entry for SAPTRANSHOST to point to the particular system’s central instance.

20. Verify that Internet Explorer is at version 5.x.

21. OPTIONAL – after the ENTIRE SAP INSTALLATION, go back to Control Panel, System, Performance, and change ‘foreground’ to ‘background’ – this ensures that a locally logged-on user does not rob the logged-in SAP R/3 clients of their otherwise entitled memory/processor cycles. You may also wish to load any array configuration or management utilities locally on the server, too, to facilitate future change control/troubleshooting.

Prepare for the DB and R/3 installation

1. Read through the pertinent INSTALLATION guide (InstGuide – print it, make it easy on yourself!) and the standard SAP product guide (may be found on CD with the installation kit)

2. Request that the SAP Basis team obtain any pertinent SAP Notes – see the InstGuide for a list of pertinent notes, and read these – they may impact the basic setup of the server/infrastructure.

Welcome to Techstall.com. Techstall is your onestop place for tech blogs, chats & tech articles. 

 A must read blog!  I spent a year in the trenches, and learned a lot from my technical & funtional experience in Information technology. I only wish that this blog was available earlier for myself and other , so we could share ideas . Some of the pitfalls I ran into during our own implementation; before project preparation, Go-Live would have undoubtedly proved valuable over and over again. In fact, I expect that much of the information and best practices found inside will still prove useful to me going forward, even nearly a year and a half after “Go Live”. To all joining this blog or just accessing information, Techstall will at its best ability to present the facts logically and in an easy-to-read and comprehend manner – while keeping things interesting along the way – makes it a pleasure to add this blog to my collection. So folks lets add share and enjoy…….Start blogging!