گروه: http://groups.google.com/group/modiriran/topics
- رهایی از کرم جاسوس که اطلاعات شما را کپی می کند [1 به روزرسانی]
- آنچه که یک مدیر از یک تحلیلگر کسب و کار باید انتظار داشته باشد [1 به روزرسانی]
- "مدیران ایران" <info@modiriran.ir> Sep 16 11:40AM +0430 ^
*کرم خطرناک رایانه ها و آنتی ویروس مخصوص آن*
رایانه های ایران مورد هجوم شدید کرم خطرناک رایانه ای به نام Stuxnet قرار
گرفته اند که تلاش می کند اطلاعات سیستمهای کنترل صنعتی را به سرقت برده و آنها
را بر روی اینترنت قرار دهد. اندونزی و هندوستان نیز به واسطه این نرم افزار
مخرب مورد هجوم قرار گرفته اند.
بر اساس اطلاعات جمع آوری شده توسط شرکت "سایمنتک" در حدود ۶۰ درصد از سیستمهای
رایانه ای که به این ویروس آلوده شده اند در ایران قرار دارند. اندونزی و
هندوستان نیز به واسطه این نرم افزار مخرب که به Stuxnet شهرت دارد مورد هجوم
قرار گرفته اند.
به گفته "الیاس لووی" مدیر ارشد فنی بخش "پاسخگویی ایمنی سایمنتک" با توجه به
تاریخ نشانه های دیجیتالی که از این کرم رایانه ای به جا مانده، می توان گفت
این نرم افزار از ماه ژانویه سال جاری میان رایانه ها در گردش بوده است.
Stuxnet ماه گذشته توسط شرکتی به نام VirusBlockAda که اعلام کرد نرم افزاری
را بر روی سیستم رایانه یکی از مشتریان ایرانی خود مشاهده کرده، کشف شد.* این
کرم به دنبال سیستم مدیریتی SCADA زیمنس که معمولا در کارخانه های بزرگ تولیدی
و صنعتی مورد استفاده قرار می گیرد بوده و تلاش می کند اسرار صنعتی رایانه های
این کارخانه ها را بر روی اینترنت بارگذاری (Upload) کند.*
سایمنتک اعلام کرده نمی داند چرا ایران و دیگر کشورها به این اندازه تحت تاثیر
آلودگی های ویروسی قرار دارند. به گفته لووی تنها می توان گفت افرادی که این
نرم افزارهای خاص را ساخته اند، آن را ویژه حمله به این نقاط جغرافیایی خاص
طراحی کرده اند.
زیمنس تعداد مشتریان خود را در ایران را اعلام نمی کند اما به تازگی اعلام کرده
دو شرکت آلمانی نیز به واسطه این ویروس آلوده شده اند.
سایمنتک اطلاعات خود را به واسطه همکاری با صنایع و تغییر مسیر ترافیک به وجود
آمده به منظور اتصال به سرورهای کنترل و فرمان کرم رایانه ای به سوی رایانه های
خود جمع آوری کرده است. طی دوره ای سه روزه رایانه هایی که در ۱۴ هزار آدرس IP
حضور داشتند تلاش کردند با این سرورهای کنترل و فرمان ارتباط برقرار کنند که
این نشان می دهد تعداد کمی از رایانه های خانگی در سرتاسر جهان به این کرم
آلوده شده اند. تعداد دقیق رایانه های آلوده می تواند در حدود ۱۵ تا ۲۰ هزار
باشد زیرا بسیاری از شرکتها برای چند رایانه یک آدرس IP در نظر می گیرند.
به این دلیل که سایمنتک می تواند آدرسهای IP مورد استفاده سیستمهای رایانه ای
را برای اتصال به سرورهای کنترل و فرمان مشاهده کند، می تواند تعیین کند کدام
رایانه آلوده شده است. به گفته این شرکت رایانه های آلوده شده به سازمانهای
متعددی تعلق داشتند که از نرم افزار و سیستمهای SCADA استفاده می کردند، ویژگی
که به روشنی مورد هدف حمله هکرها بوده است.
بر اساس گزارش PCworld، کرم Stuxnet توسط ابزارهای USB دار انتقال پیدا می کند،
زمانی که ابزاری آلوده به این شکل به رایانه اتصال پیدا می کند، کدهای آن به
جستجوی سیستمهای زیمنس گشته و خود را بر روی هر ابزار USB دار دیگری که بیابد،
کپی خواهد کرد.
در این خصوص روز گذشته عضو هيات رييسه سنديكاي توليدكنندگان فنآوري اطلاعات
گفت که به كليه سازمانها، افراد و شركتهاي صنعتي و غيرصنعتي درباره كرمي كه
اخيرا بسياري از رايانههاي ايراني را آلوده كرده، نامه نوشته و به آنها هشدار
دادهايم.
متاسفانه درباره كرم اخيري كه حدود 60 درصد از رايانههاي ايراني را آلوده كرده
اطلاعرساني مناسبي نشده و البته هيچ متولي مشخصي نيز در اين زمينه در كشور
وجود ندارد.
وي با بيان اينكه وزارت ارتباطات و فنآوري اطلاعات بايد در زمينه
اطلاعرساني درباره ويروسها و كرمهاي آلودهكننده قويتر عمل كند، عنوان كرد
حتي ستاد پيشگيري از حوادث غيرمترقبه در كشور ميتواند در اين زمينه فعالتر
عمل كند، چرا كه آلودگي 60 درصد از رايانههاي كشور به اين كرم خطر كمتري نسبت
به زلزله يا سيل ندارد.
*برای بررسی آلوده بودن وضعیت رایانه ی خود ابتدا برنامه ی همراه این نامه را
نصب نبوده و سپس با کمک دکمه ی check it کامپیوتر خود را بررسی نمایید .
*
* این برنامه در صورت آلوده بودن به سادگی این کرم خطرناک را از روی کامپیوتر
شما حذف خواهد نمود ...*
http://onlinemanagers.ir/EMag/ContentDetails.aspx?cid=556
- Mohammad Reza Jalali <mrjalali@yahoo.com> Sep 14 10:08PM -0700 ^
مدیران محترم!
اگر تحلیلگران سیستم یا تحلیلگران کسب و کار شما به وظایف زیر آشنایی ندارند و شما
نمی توانید چنین انتظاراتی را از آنها داشته و چنین خدماتی را از آنها دریافت کنید،
سازمان شما فقط دارای کارمندان آرشیو نگهداری دستورالعلهای فرمالیته اداری یا
تجویزی ایزوهای مختلف است ویا برنامه نویسان صرفا متبحر کامپیوتری هستند که به سرعت
وضع موجود شما را مکانیزه می نمایند
Business Analysis is a term that covers a wide range of different disciplines,
which has grown in scope over the past 10-15 years. BAs can become involved in
a variety of different activities, depending on the organization and the
particular project that they are working on – these can range from very
technical to very business focused activities.
So if you're working as a Business Analyst, or working with a Business Analyst,
what can you expect? I've split this article into two sections, firstly
focusing on the activities that a BA can perform and secondly looking at the
job titles that they can hold.
Part 1: Activities
You should expect the following characteristics and capabilities to apply to all
BAs as standard:
* logical thinking
* constructive challenge
* independent perspective
* broad knowledge of both business and technical concepts
* problem solving
* facilitation and negotiation
However, they can use these capabilities to perform different activities which
are briefly explained below:
System analysis
Nowadays, most BAs will not be responsible for systems analysis, and some will
deliberately steer well clear of it. However, it used to be the case that what
an organization called a business analyst was in fact a systems analyst and
this is still the case in some businesses.
Whilst you can argue that an organization or business function is as much of a
system as an AS/400 application, systems analysis tends to be geared towards
technology. The BA in this context is interested in determining how an existing
system works so that changes can be specified – and in my experience, systems
analysis tends to be a term applied to existing systems rather than new
developments. Systems analysis in this context provides a better understanding
of an existing situation to inform requirements definition and design. Having
said that, systems analysis can be applied to new systems, and can be
particularly relevant if needing to frame requirements within the context of a
defined technology.
Enterprise analysis
This is a more recent term which tends to be applied to more strategic analysis
roles that sit very close to the business. This role involves assessment of
business strategy, definition of vision, strategy and business goals as well as
development of business cases in close consultation with sponsors. It can have
a sizeable crossover with business architecture activity but this is not always
the case – I prefer to think of this as distinct activity that covers what the
business wants to do and why, whereas business architecture considers how it
will be achieved and the impacts on the current operations.
Requirement analysis
Requirements analysis is by far the most common role for a Business Analyst,
and can be considered the bread and butter activity for many BAs. This is
concerned with eliciting, documenting and analyzing the problems that the
business is experiencing, translating these into requirements and effectively
communicating them to those that will design and build a solution.
Business partner
This is a less common role but it does exist and can tie in closely with
Enterprise Analysis. This role sits very close to the business, often to only
one or two individuals and acts in a consultative capacity, providing advice
relating to business change or specific concepts such as benefits management.
A variation on this activity is for the role to provide a focal point for
Business Analysis resource for a particular business unit, with the
responsibility for performing feasibility analysis, subsequently allocating BAs
to individual projects and providing guidance across that business unit's
portfolio
Feasibility analysis
Feasibility analysis is another common role for a BA to fulfill; this relates
to the upfront shaping and scoping of business change and the assessment as to
whether the organization should proceed with a project to deliver it. This role
can include business case development as well as requirements definition,
although the latter will be at a high level . Feasibility analysis often
includes vendor selection processes such as Request For Information (RFI) and
Request For Proposal (RFP) and as a minimum, the BA should define the
requirements and participate in the scoring process. In some organizations the
BA runs the whole RFI/RFP process, but ideally this should be managed by
procurement professionals.
Data analysis
This is another "technical" role that many BAs will not be required to perform.
Note that data analysis is distinct from data modeling (conceptual or logical)
which is a core BA skill, and should be part of requirements definition. Data
analysis is concerned with understanding existing data items and data structure
in order to specify detailed requirements or (more likely) inform the design
and should really be considered a technical design activity rather than a
business analysis one; however, some organizations will categorize this as the
latter.
Process analysis
Whilst some organizations have specific teams dedicated to process analysis
(often relating to LEAN concepts), Business Analysts often become involved in
process analysis on a project. Most business change results in some impact on
business processes, and therefore there is a need to determine which processes
need to change (and how) and this is again a core skill for a BA. This activity
involves both traditional analysis and facilitation, as well as resulting in
high quality documentation relating to the as-is and to-be processes.
Organizational analysis
This activity is becoming more and more common, although it is still something
of a rarity. organizational analysis itself is concerned with understanding
what elements of an organization need to change to accommodate a business
change. Many organizations prefer to use a third party consultancy firm to
perform this, both from a transferral of risk perspective (having someone else
to blame) and from a lack of awareness that these skills exist internally.
organizational analysis is classic analysis activity, in terms of defining the
as-is and to-be states and analyzing the gaps between them, or analyzing
specific impacts across an as-is organizational model. This can include both
the structure of the organization in terms of reporting lines as well as
precise measures such as spans of control. Note that this analysis is often
focused on the hierarchical organizational model rather than on the overall
operating model which is where Business Architecture comes in.
Business Architecture
Business Architecture encompasses organizational analysis (and indeed other
types of analysis) but is distinct in that it brings a higher level perspective
by focusing on the entire operating model. This could be across the whole
organization, or it could be focused on a particular business area. It
considers the customers of the subject area, the services or products that it
offers and the channels that it uses to offer those services as well as how the
business is organized and where it is located.
There are a variety of different frameworks used for Business Architecture
including Zachman, TOGAF and POLDAT but all of them focus on holistic analysis
of the subject area and the relationships between different elements.
The actual capability to perform Business Architecture is not too dissimilar to
core Business Analysis, although it does require training to use a particular
model. Given the exposure that this role is likely to have, it is suited to
those analysts who have experience in influencing and negotiating with senior
stakeholders as well as those who are comfortable with cross-functional
analysis throughout the entire project lifecycle, as opposed to just detailed
requirements gathering.
Part 2: Job titles and role
Several organizations distinguish the levels of experience of their Business
Analysts through different job titles, for example Senior BA, Lead BA,
Principal BA and so on. One of the benefits of this sort of structure is that
it gives a clear career path. However, this can cause confusion in practical
terms, as someone who is defined as a "Lead BA" may not in fact be acting as a
lead on a project, whilst someone defined as a "Business Analyst" may be
leading a team of other analysts but not have the title of "Lead". Also, it
does lead to certain behaviours by making the grade of the individual visible
to all concerned (for example on your email signature). This can result in a
team of ambitious BAs who are constantly pushing to move up to the next level
for the kudos associated with a rise in rank and ultimately with more
"managers" and less "doers". I have seen situations following a promotion to a
more senior role whereby the BA is less inclined to perform core analysis
activity or where they won't be assigned to a particular project because the
work that is required doesn't reflect their new title: "you can't assign Jane
to that project, she's a Lead BA".
There is nothing wrong with ambition, and people should be encouraged to
perform at their full potential; however, organizations need to balance the
demand for analysis resource with the need to reward high performers and if the
only way to reward staff is to give them a management role then the
organization may quickly run out of individuals that are actually doing any
work.
This situation also has a negative effect on the individuals who are not being
moved up to the Senior or Lead grade; they will see colleagues promoted that
are subsequently considered "too senior" to work on the projects that they
themselves are working on, thereby degrading the work that they are performing.
This can have a huge effect on team morale, leading to a "them and us"
mentality amongst BAs.
My preference is to separate the role from the grade and move away from the
militaristic use of rank when referring to BAs. The role of "Lead BA" is an
important one, but it should relate to the temporary role that a BA performs on
a specific project, not their job title. I could act as the lead BA on one
project, but as a regular BA on the next.
There is still a need for some form of distinction within an organization to
define pay and rations and reward those who take on extra responsibility but I
don't think this should be part of the job title. My preference is for 3 key
roles, none of which imply any seniority over the others and none of which are
necessarily job titles.
Business Analyst
The BA performs Requirements Definition, Requirements Analysis and System
modeling on a specific workstream or project, receiving direction from a Lead
BA. The BA will perform the key analysis activities on the project, such as
facilitating workshops, producing models and analyzing requirements
Lead BA
A lead BA is the person responsible for the Business Analysis deliverables on a
project with multiple analysis workstreams; they will be responsible for
providing team leadership and direction to the individual workstream BAs,
whether this is a physical or virtual team, and will perform this role
throughout the life of the project. The lead BA may be responsible for shaping
and scoping the BA deliverables at the start of the project, and may be the
person who conducts the initial feasibility analysis. In this regard there can
be crossover with the role of the Enterprise Analyst although the latter will
tend to perform analysis before a project is defined.
Enterprise Analyst
This role tends to work on pre-project activities, working closely with the
business to shape concepts, develop business cases and in some cases conduct
feasibility studies. The Enterprise Analyst works cross-functionally, examining
the impact and benefits of the proposed change across the whole business. Where
required, the Enterprise Analyst will also fulfill the Business Partner role
discussed in part 1 above.
Summary
Hopefully this article has explained that varied role that BAs can play
throughout the project lifecycle, and has touched on the value that they can
add. I also hope that the article has stimulated some debate around the
different job titles that they can hold. I don't know how successful separating
role from grade will be in practice and I'd be interested to hear feedback from
anyone who has come across similar issues with job titles and how they've
resolved them.
Author: Joseph Da Silva, Principal Business Analyst, Skandia
Joseph Da Silva is a Conference Speaker for the Business Analysis Conference
Europe 2010.
He will be presenting the following session: "Nobody Knows Your Business Like
Your Own Business Analysts" at the conference.
Joseph Da Silva has been a Business Analyst for over 10 years, working on major
business change projects for the likes of IBM, Virgin Media and now Skandia.
His current role at Skandia involves heading up the Business Consultancy
practice within the Business Analysis team which focuses on cross-functional
feasibility and enterprise analysis, as well as process and quality
improvements. He is a keen musician, runner and football fan.
________________________________
شما این ایمیل را به خاطر عضویت در گروه " جامعه مجازی مدیران ایران" دریافت نموده اید.
برای ارسال ایمیل به گروه : modiriran@googlegroups.com
آدرس ایمیل برای لغو عضویت : modiriran+unsubscribe@googlegroups.com
اطلاعات بیشتر : http://groups.google.com/group/modiriran?hl=fa
www.modiran-iran.ir - www.ModirIran.ir - www.OnlineManagers.ir
هیچ نظری موجود نیست:
ارسال یک نظر