1) If you're in position of something that will be implemented but won't be effective, it seems the CFO makes the questions and the answers by already having chosen the solution to its problem. Because you're a professional and you see details that he cannot, you assume that it won't work. But the problem is not here. YOU should be the decider of the technical solution. So :
a) Your CFO recognize you as a technical authority, he has a problem for which he already has fancied a solution; tell him gently that how urgent and/or important it is, it is a classical project that should holds within a window of money, time, and human resources. Have an iterative process that slices the features he wants in several sub-features. As a technician, you should detail the precise tasks that each feature involves and not say "well, implementing a BI is 2 weeks/months/years" without knowing what you will precisely have to do. The matter is not to have precise estimations of what time it would take, but what we gonna do exactly (and most important, what we are NOT going to do). Based on that, you will have more people or more resources or more money or most probably, a reduced feature set, that would be less sexy but more realistic.
b) Your CFO does not recognize you as an authority in choosing BI solution and does not want to hear what you have to say, he just wants the job to be done and has read a lousy article in "BI magazine" that comforts him in asking you to do this way. Go see the one he reports to, aka the CEO. Ask him to remind the CFO that he is not a technical authority and that you are responsible for technical success and failures. If necessary organize a meeting with all three because if it is really important it would lead to a more strategic decision.
If the CEO fully supports your CFO and does not want to recognize there is a problem or a misunderstanding, it means either you are too low technically or that they are stupid. Go back training or find another company, because you will never learn or work efficiently there.
2) If the project has really to be launched in two weeks, a honest product manager will recognize that there are sacrifices to me made, only a junior fanciful guy would still want everything to be finished (in that case, go see the one he reports to). Most important, communicate and never take this kind of decision yourself; this guy has done mistakes, he has to take the responsibility of it. But even better: help him. Present him some realistic alternatives.
Make a inventory of what is finished and what is not. Ask your project manager for the priorities and focus on the first priorities, forget the rest. Be honest and realistic of what you can do. If necessary, implement some "hacks" that will do the trick in a dirty way BUT presenting good interfaces to other layers/partners. For example, if your job is to fill a table with some values, have your table ready at least in its structure. If the values of some columns are the results of computations, present approximated results, even roughly. Negotiate two have two or four more weeks to finish the job after the launch date.
It is easier for a manager or a director to tell that the project is working in a 1.0 version but some features had to be delayed in a 1.1 version, rather than tell that everything is fucked up.
If you see that every project manager in the company is doing the same mistakes but they never want to hear about compromises, and the hierarchy blindly support them because "we have to catch up with the market/the customer", go away. They need technical slaves that will undergo a very high pressure but they don't need a high-level guy as your are. 🙂