Indeed as businesses and technology solutions have gone more complex, business analysis has emerged as a specialty instead of a small responsibility within a larger programmer or programmer analyst role.
If the organisation can afford, the BA can focus more on the business side, while keeping an understanding of the technical challenges.
The SA can worry more about the technical side of existing systems and proposed architecture, while still keeping an eye on the business needs. Caroline, That sounds like a great approach and that it would help individuals on both sides stay involved and informed without the burden of too many extraneous meetings.
Thanks again for sharing. On our most recent project we found that the best time to bring our SAs into our business discussions is when we have an initial draft of the requirements and are doing a walk-thru with the business. We can ensure the requirements are being met by the solution and can be traced.
Your point is well taken — it is more of a gray zone, or a middle ground than I made it sound in my first post!
Thanks, Caroline, for your detail on how the role works in your organization. Do your SAs have the opportunity to shadow you in your conversations with the business? And do your BAs stay involved in some of the solutions discussions? In my experience in what would be considered a BSA role in this context, many trade-offs happen in the middle of that space, and some shared knowledge and input might be beneficial.
I thoroughly enjoyed reading all the comments above which illuminate and give insight on the dilemma of BA vs SA. I faced a similar dilemma when I recently joined an organization that never had BAs before. That distinction typically translates into the BA working on business requirements from process down to the functional requirement level and the SA taking over at that point with system design. One downside of this arrangement is that we sometimes find our carefully traced functional requirements changing as the more tangible solution discussions highlight better ways to accomplish some detailed requirements.
When this happens its usually because the BA got caught in the trap of defining the how and not the what! We are still working through this arrangement of the BA and SA roles and how they work together.
Tom, This article discovered via a Tweet by Julian Sammy highlights the historical use of the systems analyst title and provides a nice history of the role as well. They often did all the user interfacing on larger projects. The I realized the stuff that was really interesting to me seemed to all be in the BA portion so I am busily trying to become a better BA.
Again that notion of managing expectations!!! That is a huge — and vastly undocumented — part of our role. Please ensure the advice is backed up with numbers!! Mature organizations want BA to collect and document requirements.
In this model a BA who strays from strict requirements processing will risk trouble. But is smaller or less-mature organizations, expectations about BAs are very different. Such organizations see requirements as pretty obvious and care much more about the solution.
My point is specifically that BAs are SAs in this sense. Elucidating the deeper structures of office behavior as in BPM is precisely the activity of analyzing the systems that support the business whether the technologies are English and telephones, multi-part carbon paper forms, or wikis. Forums with Input from Topic Experts.
Industry Webinars. Interview Questions and Answers. Salary Information. Industry News and Press Releases. Monthly eJournal , and much more. Posted by Adrian M. ANSWER While the differences between the business analyst BA and systems analyst SA vary from organization to organization, there are some acceptable differences: Role and Responsibilities Business Analyst - BA : The business analyst's main role is to understand the business processes and procedures how the business works , to identify areas of improvement problem areas , and to work with the business stakeholders to identify suitable solutions.
Mathangi posted on Thursday, November 19, AM. Serafettin posted on Wednesday, July 21, AM. Dimension 1: Requirements The focus of a Business Analyst is on business requirements — particularly from a business process perspective — including work activities, workflows, work activity procedures, mechanisms including supporting information systems , roles, organization reporting relationships, etc.
Dimension 2: Scope The scope of a Business Analyst is on solutions to business problems — often from a cross enterprise perspective. Dimension 4: Analysis Tools Business Analysts use business analysis related models and diagrams such as process maps, organizational structure diagrams, strategy maps, role reporting relationships, etc.
The Inteq Group is uniquely qualified to assist your organization with this challenge. He frequently lectures on business strategy, innovation and business transformation and serves on the board of commercial and non-profit organizations.
In his book, Mastering Business Chaos, he reveals secret patterns he has discovered in thousands of client interactions ranging from Fortune to emerging growth companies and government agencies throughout the spectrum of industry.
The Inteq Group is a team of top industry professionals that provide business analysis training and consulting services, application software development services, and big data solutions to commercial and governmental organizations worldwide. Proctor has a B. He started his career with the firm of Ernst and Young formerly, Ernst and Whinney with their consulting group in Dallas and specialized in the aerospace, financial services, manufacturing and defense industries. About Us.
Recommended Courses. Subscribe to Our Blog. Recent Posts. Business Process Mapping vs. Business Process Mining.
0コメント